On Sun, 28 Oct 2001 19:59:47 EST, jmjonesat_private said: > For the peanut gallery, and because this concern seems to be outside LSM's > defined concern of "access restriction" (which is a hazy and largish > area), I would like to state that I don't see the ptrace problem as being > within the interest/scope of LSM, but I do see it as being within the > scope of Linux Security. Actually "access control" is defined with mathematical rigor. The part that's fuzzy is trying to get a handle on all the *other* security issues that fall outside a anal-retentively strict definition of "access control". For an example of what I mean (and what I'm looking at at this moment), go look at http://www.grsecurity.net, where they've produced a patch that includes Solar Designer's OpenWall stuff, plus a few other things. There's an amazing amount of Really Good Ideas there, and a lot of them are addressable through the current LSM hooks, since they're just access control (for instance, "dont follow symlinks in a world-writable directory unless the owner of the symlink matches the owner of the directory" - will do wonders for fixing /tmp races once and for all, and isn't all that hard to do in the LSM world. On the other hand, although there's certainly value to be gained in randomizing the PID returned by fork(), or making the stack non-executable, or causing the base address of mmap() to return a semi-random value so shared libraries load at different points each time, I don't see how to do these in the LSM context (at least not for V1). I think we have a pretty good grasp on how to add auditing for the next turn of the crank - but there's a lot of stuff that it isn't clear how to do it in an LSM context. /Valdis _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Sun Oct 28 2001 - 21:38:32 PST