[apparmor] [PATCH RFC] Add profile-based libapparmor query interface
Tyler Hicks
tyhicks at canonical.com
Fri Mar 8 00:17:39 UTC 2013
On 2013-03-07 14:52:06, Seth Arnold wrote:
> On Tue, Mar 05, 2013 at 10:44:35PM -0800, Tyler Hicks wrote:
> > + *allowed = mask & (allow & ~deny) ? 1 : 0;
> > + if (!(*allowed))
> > + audit = 0xFFFFFFFF;
> > + *audited = mask & (audit & ~quiet) ? 1 : 0;
> > +
> > + return 0;
> > +}
>
> When I first saw this, I thought it through, and it made sense.
>
> But it kept me awake last night, wondering about it.
Sorry about that. It was just a silly little trick that I came up with
while throwing the patch together. :)
>
> It conflates the two concepts of "report this denial as usual" and "the
> admin has written policy asking for this to be reported".
>
> So long as everything is reported, the right thing happens in the end.
> But I could easily see a trusted program wanting to rate limit the
> "usual denials" to one per {client, method} per second. But if the
> admin has asked specific resource denials to be audited, perhaps it
> ought to log on every attempt, regardless of rate limiting?
>
> Am I just overcomplicating things?
No, it is a potentially valid use case but I'm trying to keep this
interface simple so that most applications don't have to worry about
bitwise operations of four permission masks that come from the kernel.
It seems like overkill to me in most cases.
Does the AA kernel code do any type of audit rate limiting like this?
Tyler
>
> Thanks
> --
> AppArmor mailing list
> AppArmor at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20130307/b5dae027/attachment-0001.pgp>
More information about the AppArmor
mailing list