Hi!
> 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".
Why not? I think solution should be other way around: we limit
capabilities to those found in inode, but never set capabilities. That
way, FS_DAC_OVERRIDE-setcap-program will be setuid root, but will have
info in inode that it only really needs FS_DAC_OVERRIDE. This is how
elfcap works, and I think that's good.
> 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. :-)
If you use capabilities as I did in elfcap, you'll see setuid
bits.
Pavel
-- The best software in life is free (not shareware)! Pavel GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+- 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