On Mon, Apr 20, 2009 at 03:49:49PM -0400, Eric Paris wrote: > >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? I have had a better thought on this all and now I'm sure, that it would be optimal to have single access permission that will not mean permitting/denying access(2) calls, but will control the audit messages generation (depending on the actual access we have got). If we will just allow averyone silently call access(2) on every file we will only have one problem that is an information leakage. To prevent that information leak in some cases or in all cases except some cases we will use access permission (will it be enough to have one single access?). So, simply not having access permission will generate audit messages only when access(2) returns "NO ACCESS", but will generate nothing if there is access. If access permission will be dontaudited OR allowed, then that will mean we don't care at all if someone is probing permissions, that are not permitted to him (we trust him enough). This is not typical for SELinux to have same meaning for dontaudit and allow, but see, we are only trying to decide whether we are to AUDIT some actions, not to permit/deny some access. Right? Or you gonna make it possible to deny access(2) call at all? I wonder if that would be useful. -- Alexey S -- 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.
