On Fri, 24 Jun 2005 14:41:45 EDT, Karl MacMillan said: > > -----Original Message----- > > From: Ivan Gyurdiev [mailto:gyurdiev@xxxxxxxxxx] > > Sent: Friday, June 24, 2005 2:33 PM > > To: Brian T. Sniffen > > Cc: Karl MacMillan; selinux@xxxxxxxxxxxxx > > Subject: Re: Alternative user management approach > > > > On Fri, 2005-06-24 at 14:09 -0400, Brian T. Sniffen wrote: > > > "Karl MacMillan" <kmacmillan@xxxxxxxxxx> writes: > > > > > > > This makes the SELinux user more what we are calling a 'user > > > > role'. For example, the policy could create 3 user roles with > > > > different role authorizations (which become 'role capabilities'): > > > > > > This seems like a great innovation. But it does inherit one problem > > > of generic user_u: there's no longer any MAC separating users. If I'm > > > a normal user, my shell has exactly the same security context as your > > > shell---right? > > > > Is the user info used for anything besides rbac? > > I don't think it is... > > > > It can be used for constraints. There have been some suggested uses for this, > but none are currently implemented in real policies. User separation seems > better left to DAC. I think I was the guy who started the whole constraints discussion ;) And for the most part, yes DAC is sufficient - but there's a few things I'd like to apply at the MAC level using constraints. I'd much rather have one user_u with 20-30 locally added ($u1 != $u2) constraints than have to drag around user1_u..user1000_u with corresponding ruleset explosion....
Attachment:
pgpw8Dn1nSZqE.pgp
Description: PGP signature