El mar, 15-02-2005 a las 23:21 -0500, Valdis.Kletnieks@private 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@private> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
This archive was generated by hypermail 2.1.3 : Wed Feb 16 2005 - 05:30:22 PST