On Tue, 11 Nov 2003 00:10:49 EST, "Serge E. Hallyn" said: > I guess I've been calling /home/s01 the (or a) "jail parent." Then /home/s01/u1 > would be a jail. That was just more concise than having to list each of 100k > user directories. (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....) 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). Likewise, I can't convince myself that the fact that a given dentry can be either on the read exception list or execute exception list, but not both, isn't a whoops waiting to happen. Similarly for the inheritance to subdirectories - is there an easy way to say "/foo is on the read exception list, and /foo/a, /foo/b, and /foo/d are, but /foo/c is *NOT*"? (This becomes important for things like /usr/lib, where many systems store mixes of binaries, shared libs, and data). 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? If it wasn't 3AM, I could probably come up with some clever race condition involving very deep trees and abuse of ../.., or abuse/races on #!, or unlinking the cwd, or other odd corner cases. There's an awful lot of code out there that assumes that what stat()/access() return actually corresponds to reality.....
This archive was generated by hypermail 2b30 : Mon Nov 10 2003 - 23:58:14 PST