On Mon, 2009-04-20 at 15:28 -0400, James Carter wrote: > On Mon, 2009-04-20 at 15:08 -0400, Eric Paris wrote: > > On Mon, 2009-04-20 at 14:55 -0400, James Carter wrote: > > > On Mon, 2009-04-20 at 11:11 -0400, Eric Paris wrote: > > > > > > I strongly and vehemently oppose any solution that is a blanket > > > > dontaudit on access calls, even if there is a flag to dontdonaudit. > > > > This might be fine in "secure" shops where everyone understands and is > > > > willing to suffer some extra SELinux pain but not here. If SELinux gets > > > > in the way it better scream to high heavens for my customers. > > > > > > > > > > I think that what we need is a check to see if the domain is allowed to > > > call access() on the object. If it is not allowed, then a denial is > > > generated; if it is, then the results of the desired permission check is > > > returned, but denials are not audited. > > > > > > This would better reflect what is actually happening. When a domain > > > calls access(), it is really reading the security properties of the > > > object. > > > > Your still just talking about a big global dontaudit hammer on the > > EACCESS people get back from access(). Not only that, you propose a new > > permission every domain needs of which I don't see any security benefit > > (outside of maybe helping make sure people can't probe policy willy > > nilly). > > > If you don't care whether or not someone is probing the policy, then why > not just always use the _noaudit interfaces? >From where I sit, I don't care if people probe the policy. The problem I want to solve is that we have dontaudit rules against what I consider valuable resources. (eg: shadow and krb5 files) But, I certainly understand why others might care (which is the lesser of the two reasons I don't like the _noaudit, interface on access()). So I think my kernel patch prototype allows the policy to decide where it cares about probing and where it doesn't. > What is the security benefit of the access_* permissions? It looks like > they are only going to be used to determine if a denial should be > generated. Very little security benefit other than we can remove all of the dontaudit rules trying to read shadow_t. Instead we'll have dontaudit rules for trying to probe if you can read shadow_t. Actually trying to read shadow_t would begin to generate a denial. Today neither activity would generate a denial. access_* permissions would have NO meaning other than in the dontaudit case (could also do auditallow) Let me summarize where I'm coming from. Problem: Many programs use access() to chose which code path to use thus requesting permissions granted by DAC, but we choose to deny through SELinux policy. Thus we currently must dontaudit all read, write, and execute for these situations. Eric's Restrictions on solutions: If SELinux denies access SELinux must is some way inform the user that it denied access. Other's Restrictions: Do not make tool chain significantly more brittle? Maintain ability to detect probing of security policy? Am I missing something? Does my latest kernel prototype meet these needs? -- 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.
