On Mon, Nov 15, 2010 at 12:04 PM, Eric Paris wrote: > On Sat, Nov 13, 2010 at 3:31 PM, Linus Torvalds > wrote: >> We had this exact problem with the whole "mmap_min_addr" thing. People >> _thought_ of it as generic, but because it was actually tested by the >> security logic, if you ended up enabling SELinux the test actually >> went away entirely (or maybe it was the other way around). So with >> certain security models, the whole thing was bypassed, and the >> security module actually became an _IN_security module. > > Your recollection is wrong, although your conclusions of the > ramifications are right.  Either SELinux or capabilities checked > mmap_min_addr, depending on which was 'primary.'  Just as they are > different modules they checked for different things.  Only doing > SELinux checks was stronger for some situations, and only doing > capability checks was stronger in some ways (and the reverse was > obviously true).  Today you get the best of both worlds since we > really have 2 different mmap_min_addr values... > > In any case the result of that is that LSMs (ok 'I') need to be more > careful making sure they interact properly with the generic > capabilities hooks. > > From: James Morris >> I want to ensure that LSMs which implement security_syslog can't end up >> with a less secure system than the default, regardless of whether they >> call cap_syslog or not. > > Which really means that this is total crap.  If you don't call > cap_syslog() you broke it.  That's all there is to it.  Calling the > capability code is always required.  full stop. > > I think this patch is broken though.  SELinux and SMACK don't care > about from_file and want to check every time no matter what.  Your > patch breaks that and only will call the LSM on occasion.  It's only > capabilities that likes those semantics.  I think the entire contents > of the cap_syslog hook should be moved up and that hook just dropped > entirely. > > I'll code up what I'm thinking in a minute..... > > -Eric I'm sure somebody somewhere hates it, but I was thinking something like the attached. include/linux/security.h | 9 ++++----- kernel/printk.c | 11 ++++++++++- security/capability.c | 5 +++++ security/commoncap.c | 21 --------------------- security/security.c | 4 ++-- security/selinux/hooks.c | 6 +----- security/smack/smack_lsm.c | 8 ++------ 7 files changed, 24 insertions(+), 40 deletions(-) (Personally I think that most of the hooks in commoncap.c code should be moved out of security/ altogether and we should completely do away with our current ghetto inter LSM calls. But that's just me) -Eric