All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linda Knippers <linda.knippers@hp.com>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: casey@schaufler-ca.com, "Ahmed S. Darwish" <darwish.07@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	James Morris <jmorris@namei.org>, Paul Moore <paul.moore@hp.com>,
	LKML <linux-kernel@vger.kernel.org>,
	LSM-ML <linux-security-module@vger.kernel.org>,
	Audit-ML <linux-audit@redhat.com>,
	Steve Grubb <sgrubb@redhat.com>
Subject: Re: [RFC][PATCH -v2] Smack: Integrate with Audit
Date: Wed, 12 Mar 2008 12:23:29 -0400	[thread overview]
Message-ID: <47D80381.3030001@hp.com> (raw)
In-Reply-To: <1205336897.23866.296.camel@moss-spartans.epoch.ncsc.mil>

Stephen Smalley wrote:
> On Wed, 2008-03-12 at 08:40 -0700, Casey Schaufler wrote:
>> --- Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>
>>> On Wed, 2008-03-12 at 04:44 +0200, Ahmed S. Darwish wrote:
>>>> Hi!,
>>>>
>>>> Setup the new Audit hooks for Smack. The AUDIT_SUBJ_USER and 
>>>> AUDIT_OBJ_USER SELinux flags are recycled to avoid `auditd' 
>>>> userspace modifications. Smack only needs auditing on 
>>>> a subject/object bases, so those flags were enough.
>>> Only question I have is whether audit folks are ok with reuse of the
>>> flags in this manner, and whether the _USER flag is best suited for this
>>> purpose if you are going to reuse an existing flag (since Smack label
>>> seems more like a SELinux type than a SELinux user).
>> To-mate-o toe-maht-o.
>>
>> There really doesn't seem to be any real reason to create a new
>> flag just because the granularity is different. The choice between
>> _USER and _TYPE (and _ROLE for that matter) is arbitrary from a
>> functional point of view. I say that since Smack has users, but
>> not types or roles, _USER makes the most sense.
> 
> Perhaps I misunderstand, but Smack labels don't represent users (i.e.
> user identity) in any way, so it seemed like a mismatch to use the _USER
> flag there.  Whereas types in SELinux bear some similarity to Smack
> labels - simple unstructured names whose meaning is only defined by the
> policy rules.
> 
> Regardless, it seems like the audit maintainers ought to weigh in on the
> matter.

I don't count as an audit maintainer but I think as long as the
man page is updated to say something other than:

subj_user
    Program's SE Linux User

then its fine for multiple LSMs to use the same rule flags and its
better than inventing new ones for each LSM.  I don't have an opinion
on which flag that's currently specific to SELinux should be recycled
but I think the manpage could be made more generic for all of them.

>>> Certainly will confuse matters if a user has audit filters on SELinux
>>> users in their /etc/audit/audit.rules and then boots a kernel with Smack
>>> enabled.
>> Somehow I doubt that will be their biggest concern.

I agree.

-- ljk
> 


  reply	other threads:[~2008-03-12 16:23 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-10 12:49 [RFC][PATCH] Smack<->Audit integration Ahmed S. Darwish
2008-03-10 16:07 ` Casey Schaufler
2008-03-10 16:07   ` Casey Schaufler
2008-03-10 18:26   ` Ahmed S. Darwish
2008-03-10 18:26     ` Ahmed S. Darwish
2008-03-10 18:43     ` Casey Schaufler
2008-03-12  2:44       ` [RFC][PATCH -v2] Smack: Integrate with Audit Ahmed S. Darwish
2008-03-12  4:23         ` Casey Schaufler
2008-03-12 12:18           ` [PATCH -v2b] " Ahmed S. Darwish
2008-03-12 12:52         ` [RFC][PATCH -v2] " Stephen Smalley
2008-03-12 12:52           ` Stephen Smalley
2008-03-12 15:40           ` Casey Schaufler
2008-03-12 15:40             ` Casey Schaufler
2008-03-12 15:48             ` Stephen Smalley
2008-03-12 16:23               ` Linda Knippers [this message]
2008-03-12 16:43               ` Ahmed S. Darwish
2008-03-12 18:09                 ` Casey Schaufler
2008-03-13 13:55           ` Steve Grubb
2008-03-13 13:55             ` Steve Grubb

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=47D80381.3030001@hp.com \
    --to=linda.knippers@hp.com \
    --cc=akpm@linux-foundation.org \
    --cc=casey@schaufler-ca.com \
    --cc=darwish.07@gmail.com \
    --cc=jmorris@namei.org \
    --cc=linux-audit@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=paul.moore@hp.com \
    --cc=sds@tycho.nsa.gov \
    --cc=sgrubb@redhat.com \
    /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.