[prev in list] [next in list] [prev in thread] [next in thread] 

List:       selinux
Subject:    Re: access(2) vs. SELinux
From:       Alexey S <selinux () udmvt ! ru>
Date:       2009-04-22 12:41:46
Message-ID: 20090422124146.GR9889 () ruber ! office ! udmvt ! ru
[Download RAW message or body]

On Wed, Apr 22, 2009 at 04:31:05PM +0500, selinux@udmvt.ru wrote:
> 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 there can be difference.
Since there are other permissions that are tested by access(2) and they can be just denied
or dontaudited. So having access(2) to noise about dontaudited permissions sometimes looks silly,
but sometimes is what required...

It looks unnatural that dontaudit still produces audit messages. But what if
  dontaudit domain_t file_t:class { access }; 
    will produce messages when permissions are probed that are denied (and not dontaudited)
 
  allow domain_t file_t:class { access };
    will never generate audit messages on any permission probe

  deny domain_t file_t:class { access };
    will audit about probes on permissions that are denied or dontaudited

  auditallow domain_t file_t:class { access };
    will audit about any probe attempt regardless it's result (should it also audit the result?)

  auditdeny domain_t file_t:class { access };
    will audit about probes on permissions that are dontaudited (and not denied) :) why do we need this?

And I prefer audit messages generated from access(2) to be different from audits of actual actions,
but still it would be useful if audit2allow will be able to generate allow for actual permissions,
not for access permission. And it should be controlled by a switch from command line.

PS: Sorry, I'm talking with myself.
-- 
Alexey S.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
[prev in list] [next in list] [prev in thread] [next in thread]