> -----Original Message----- > From: owner-selinux@xxxxxxxxxxxxx [mailto:owner-selinux@xxxxxxxxxxxxx] On > Behalf Of Valdis.Kletnieks@xxxxxx > Sent: Tuesday, September 30, 2008 9:00 PM > To: Murray McAllister > Cc: SE Linux > Subject: Re: user guide drafts: "Working with SELinux" sections > > 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. Even with all users mapped to selinux user user_u, mcs should still be able to be used effectively. While it is true that in the case above, user_u would need to be given access to all the compartments (A - E), that does not mean that individual linux users (as opposed to the selinux user user_u) must have access to all the compartments. Individual linux users can be given access to only a subset of the compartments through the "semanange login ..." command. The compartments that individual linux users have access to can be seen using "semanage login -l", and can be set by either adding or modifying a user with "semanage login ...". For example: semanage login -a -s user_u -r A joe gives the linux user joe, access only to compartment A, even though his linux user maps to the selinux user user_u, which has access to compartments A-E -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
