From: Karl MacMillan <kmacmillan@mentalrootkit.com>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Daniel J Walsh <dwalsh@redhat.com>,
SE Linux <selinux@tycho.nsa.gov>,
Joshua Brindle <method@manicmethod.com>
Subject: Re: [Fwd: policycoreutils patches]
Date: Fri, 13 Apr 2007 11:17:28 -0400 [thread overview]
Message-ID: <1176477448.8230.21.camel@localhost.localdomain> (raw)
In-Reply-To: <1176475763.3986.248.camel@moss-spartans.epoch.ncsc.mil>
On Fri, 2007-04-13 at 10:49 -0400, Stephen Smalley wrote:
> On Fri, 2007-04-13 at 10:39 -0400, Daniel J Walsh wrote:
> > Stephen Smalley wrote:
> > > On Fri, 2007-04-13 at 08:53 -0400, Daniel J Walsh wrote:
> > >
> > >> Moved audit2allow to sbin to match audit2why.
> > >>
> > >
> > > (one patch per message would be nicer)
> > >
> > > I actually don't like having so many of the programs in /sbin
> > > or /usr/sbin, as they aren't in normal user paths and make it more
> > > painful to find the commands. And moving them can cause user confusion
> > > and/or script breakage.
> > >
> > >
> > Then for consistency we should move audit2why to the same directory as
> > audit2allow.
>
> My real preference would be that the audit2why functionality would be
> replicated (and improved) in sepolgen, and audit2allow would directly
> use that functionality to identify the cause of the denial as part of
> generating policy. Then audit2allow could directly generate refpolicy
> interface calls to e.g. add an attribute to a domain so that it passes
> some constraint, or generate a role allow rule. auditwhy in its current
> form is really only to help you; it isn't very useful for end users
> (doesn't provide enough information).
>
I would like to see that as well. We have also discussed moving the
setroubleshoot plugins into sepolgen to gain broader review and improved
maintenance. The current audit2why only provides part of the picture (as
you say), we really want to start telling users when they should relabel
a file, flib a boolean, or take some action _other_ than allowing the
access via allow rules of refpolicy interfaces.
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.
next prev parent reply other threads:[~2007-04-13 15:17 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-13 12:53 [Fwd: policycoreutils patches] Daniel J Walsh
2007-04-13 14:31 ` Stephen Smalley
2007-04-13 14:39 ` Daniel J Walsh
2007-04-13 14:49 ` Stephen Smalley
2007-04-13 14:52 ` Stephen Smalley
2007-04-13 15:10 ` Daniel J Walsh
2007-04-13 15:18 ` Stephen Smalley
2007-04-13 15:17 ` Karl MacMillan [this message]
2007-04-13 18:43 ` Stephen Smalley
2007-04-13 18:50 ` Karl MacMillan
2007-04-13 18:33 ` Karl MacMillan
2007-04-24 14:04 ` Stephen Smalley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1176477448.8230.21.camel@localhost.localdomain \
--to=kmacmillan@mentalrootkit.com \
--cc=dwalsh@redhat.com \
--cc=method@manicmethod.com \
--cc=sds@tycho.nsa.gov \
--cc=selinux@tycho.nsa.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.