On Wed, 01 Oct 2008 10:19:15 +1000, Murray McAllister said: > > Erm. What *exactly* produces that entry in /var/log/messages? > Are you referring to SELinux denying access or setroubelshoot-server? > > AVC stuff ends up in auditd. Or is this just because the setroubleshoot > > RPMs aren't *quite* as mandatory as you noted above, and I don't see those > > messages because I don't have them installed *and enabled*? (Gotta watch > > out for those pesky 'chkconfig off' ;) > I thought I tried this before writing (thinking it only went into > audit.log if setroubleshoot-server was installed, otherwise it would go > to /var/log/messages). I will fix the text up to reflect this... AVC's go into dmesg (and wherever your syslog dumps that) if auditd isn't running. AVC's goes into audit.log if auditd *is* running. If setroubleshoot is running, it reads audit.log and pretty-prints them into the syslog. > This is coming next in a separate chapter. Why can't you do much with > MCS if everyone is user_u? Doesn't it use the level, not the user/role/type? Whether you're using either the level or the classification, you need to be able to run users at different levels/classes for it to do any real good: Consider: User1 can read classes A, B, C. User2 can read classes B, D, E. User3 can read classes A, B, and E. Wow. That works pretty nice. Now consider if you only have 1 defined user for people to run as: User_u can read classes A, B, C. User_u can read classes B, D, E. User_u can read.. oh nevermind. ;) So you need to be able to say "userid fred runs as user1, userid joe runs as user2, userid dept-paperwork runs as user3/levelA, userid dept-admin runs as user3/levelB", and so on.... The stock MCS policy provides enough user classes and levels to protect the *system* from users - but you need to roll-your-own to protect user data to a similar level.
Attachment:
pgpwnUYr0VB5r.pgp
Description: PGP signature
