[lkml]   [2005]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Thoughts on the "No Linux Security Modules framework" old claims
    El mar, 15-02-2005 a las 23:21 -0500, 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

    Lorenzo Hernández García-Hierro <>
    [1024D/6F2B2DEC] & [2048g/9AE91A22][]
    [unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2005-03-22 14:10    [W:0.020 / U:8.304 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site