Re: Thoughts on the "No Linux Security Modules framework" old claims

["Lorenzo Hernández García-Hierro" <lorenzo@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 1915 bytes --]

El mar, 15-02-2005 a las 23:21 -0500, Valdis.Kletnieks@vt.edu escribió:
> On Tue, 15 Feb 2005 23:38:09 +0100, Lorenzo =?ISO-8859-1?Q?Hern=E1ndez_?= =?ISO-8859-1?Q?Garc=EDa-Hierro?= said:
> 
> > Yes, and that's noticed from the "official" documentation.
> > But, who says that we can't place auditing facilities inside the
> > existing hooks? or even file system linking related tweaks?
> 
> Many auditing policies require an audit event to be generated if the operation
> is rejected by *either* the DAC (as implemented by the file permissions
> and possibly ACLs) *or* the MAC (as implemented by the LSM exit).  However,
> in most (all?) cases, the DAC check is made *first*, and the LSM exit isn't
> even called if the DAC check fails.  As a result, if you try to open() a file
> and get -EPERM due to the file permissions, the LSM exit isn't called and
> you can't cut an audit record there.

Yes, there are many cases that apply to such scenario and context, this
may be worth to work on, but think it's main shortcoming is that it cuts
performance and adds further overlapping to the DAC checks, that should
be the first ones being called (as most times they do) and then apply
the LSM basis, so, post-processing will be only required if the DAC
checks get in override or passed, without adding too-much overhead to
the current behavior.

So, I just agree partially, but yes, maybe modifying the DAC checks
themselves and add what-ever-else helper function to handle by-default
auditing in certain operations could be interesting.

I think it could be worthy to have a roadmap in a wiki or even talk
about a one, trying to write it, so, we all could know what needs to be
improved and done, getting a higher percentage of mainline-accepted
approaches.

Cheers,
-- 
Lorenzo Hernández García-Hierro <lorenzo@gnu.org> 
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]

[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 189 bytes --]