Re: Patch to cleanup audit handling in policy.

On Thu, 2007-05-03 at 12:17 +0000, Christopher J. PeBenito wrote:
> On Wed, 2007-05-02 at 13:18 -0400, Karl MacMillan wrote:
> > On Wed, 2007-05-02 at 13:08 -0400, Christopher J. PeBenito wrote:
> > > On Tue, 2007-05-01 at 11:21 -0400, Karl MacMillan wrote:
> > > > On Tue, 2007-05-01 at 13:31 +0000, Christopher J. PeBenito wrote:
> > > > > On Mon, 2007-04-30 at 20:49 -0400, Karl MacMillan wrote:
> > > > > > Given that and
> > > > > > my concerns over their clarity I would prefer that no more patterns be
> > > > > > introduced.
> > > > > >
> > > > > > Can I ask why you are so against these audit interfaces and would prefer
> > > > > > patterns?
> > > > >
> > > > > I don't agree with the assertions which means the attributes are
> > > > > dropped, so that just leaves the rules, which don't refer to any types
> > > > > in the logging module. They only refer to resources in the current
> > > > > module (all self rules), so its not an interface, its a pattern.
> > > > >
> > > >
> > > > I think that distinction is not useful to a policy writer. As a policy
> > > > writer I think it would be natural to look for audit interfaces in
> > > > logging - by making these patterns they are harder to find.
> > > >
> > > > So - why make this distinction?
> > >
> > > Its always been the definition of an interface.
> > >
> >
> > Great - so why has that always been the definition
>
> Not sure how you can ask that since interfaces providing access to a
> module's private resource is a fundamental principle.
>

I agree that interfaces are the only way to provide access to a modules types, but I don't think that is their only purpose. They are also for grouping and organizing related access.

> > and what is the
> > motivation for separating the patterns and the interfaces in this
> > circumstance. What value does this provide to the policy writer?
>
> Indeed that is a good question, which is why I said it was compelling in
> the other thread.
>

I would suggest that for most of the patterns they don't have any other logical grouping - the access being allowed is private to the module.

These audit rules seem different. The access is really about allowing a domain access to the audit subsystem. It is not simply private access that cannot be further grouped. That the access is allowed purely via permissions on module private types is an unimportant implementation detail.

So, taking the broader definition of interfaces as grouping related access, it seems natural to make these audit interfaces and put them in logging.if.

Karl

--
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.