> (I looked at the source code, but got too fed up with all the 'state == N' lines > with N==0..5 - a bunch of #defines would help a LOT there....) Yes, that's definately worth fixing. > Since jail status is kept over fork/exec, I can see some interesting security > holes if you manage to fork/exec an suid program that expects to be able to > open a file but fails to do so - redirecting fd 0/1/2 to/from a "cant open" > file has b0rked many a set-UID program. (yes, this is still a problem with > enough software that the grsecurity patch includes a 'force 0/1/2 to /dev/null > if not open' section). The problem this was addressing was very specific: protecting apache user scripts from each other. Anything more general should not be addressed with this module. In fact, the whole purpose of the upcoming new stacker module will be to allow this to work together with , ie, DTE or SELinux. Real security should come from those. But addressing this problem with a general system like DTE would have required millions of lines of policy - defining types and domains for each of 100k users, and access rights among them. So the idea here was to write a simple LSM to simply say: Once a user's script is executed, it can't run *anything* but it's own scripts. The execution exception lists were added only becuause, of course, most scripts will use perl/python/whatever. > Does the 'exec exception list' DTRT with the old '/lib/ld-linux.so.2 your-binary-here' > hack-around that works so nicely on filesystems mounted noexec? Looks like this is a way around read and rw exception lists. That is, anything which is on the read or rw exception lists can apparently be executed this way. But anything which is not on any of those lists (which, again, should be most everything) should be safe. -serge
This archive was generated by hypermail 2b30 : Tue Nov 11 2003 - 06:15:58 PST