Date: Fri, 11 Feb 2000 13:59:43 +0000 (GMT)
From: Chris Evans <chris@ferret.lmh.ox.ac.uk>
2) Filesystem support goes in, but typical usage will be to just use the
"forced" support, to keep traditional UNIX privilege inheritance but run
suid root program with finer grained privilege. Note that stage 2) is by
no means a configuration/maintenance problem
Don't be so sure it won't be a configuration/maintenance problem. You
still have at least an order of magnitude more bits to manage, and the
traditional tools for scanning for setuid bits won't work anymore. If a
cracker installs a trojan shell which has the FS_DAC_OVERRIDE capability
bit, "ls -l" won't show it as a dangerous program. Neither will
"find / -perm +6000 -print".
If the wrong program has the wrong capability bits set, your system will
be probably be insecure. So tools that scan the filesystem to make sure
all of the capabilities are set correctly are a must, or you'll just be
handing over a huge advantage to the crackers out there. (So if
anything, I'd call not just a problem, but a configuration/maintenance
nightmare. :-)
The key point of this three stage plan is that at stage 2), you are
reaping benefits from filesystem capabilities without the hassle of
binaries not inheriting privilege in the traditional UNIX way
I agree with you that this does minimize the whiplash effect to
sysadmins. It does take away much of the advantage of using POSIX
capabilities, although granted stage (2) is still much better than what
we have today.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:20 EST