All of lore.kernel.org
 help / color / mirror / Atom feed
From: Karl MacMillan <kmacmillan@mentalrootkit.com>
To: Joshua Brindle <jbrindle@tresys.com>
Cc: Stephen Smalley <sds@tycho.nsa.gov>,
	Eric Paris <eparis@parisplace.org>,
	selinux@tycho.nsa.gov, James Morris <jmorris@redhat.com>
Subject: Re: [RFC] Ability to allow unknown class and permissions
Date: Mon, 04 Dec 2006 15:15:52 -0500	[thread overview]
Message-ID: <457481F8.5010907@mentalrootkit.com> (raw)
In-Reply-To: <6FE441CD9F0C0C479F2D88F959B015885C82D0@exchange.columbia.tresys.com>

Joshua Brindle wrote:
>> From: Karl MacMillan [mailto:kmacmillan@mentalrootkit.com] 
>>
>>> I'd prefer to avoid a selinuxfs tunable altogether, as it 
>> means that 
>>> we can't actually tell what setting was in effect for a 
>> given (kernel,
>>> policy) pair without other external data (e.g. audit record upon 
>>> setting), and it means that we cannot prepad the avtab 
>> access vectors 
>>> at policy load time (avoiding any overhead in 
>> security_compute_av at 
>>> permission check time).
>>>
>> For this to work libsemanage / libsepol needs to know about 
>> any new kernel object classes. Since the whole goal here is 
>> to not force an upgrade of the selinux packages that means 
>> that the kernel needs to export that info, correct?
>>
> 
> Refpolicy is going to begin generating 2 sets of headers soon, one for
> the kernel (with only kernel classes) and one for libselinux with
> everything. Additionally its planned for the security servers to be able
> to export the info to OM's, but that info will come from the policy, not
> the headers.
> 

Ok - but that's not related as the whole point of this exercise is to 
allow access for object classes that were unknown at policy creation time.

>> This is something that we have wanted for a while anyway as 
>> it is required to allow modules to declare object classes, 
>> userspace object managers to avoid hard coded object class / 
>> perm numbers, etc. I believe that Chad had posted some 
>> thoughts about how to do this a while ago.
>>
>> I think this is the correct solution and it has the side 
>> benefit of resulting in an interface that we wanted anyway.
>>
> 
> It doesn't give the interface I don't think, but it does let us redefine
> user object classes without worrying about the kernel rejecting it.
> 

Not certain I understand this comment either.

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.

  reply	other threads:[~2006-12-04 20:15 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-01 16:06 [RFC] Ability to allow unknown class and permissions Eric Paris
2006-12-01 17:18 ` Stephen Smalley
2006-12-01 18:41 ` Stephen Smalley
2006-12-02  3:28   ` Joshua Brindle
2006-12-04 14:46     ` Stephen Smalley
2006-12-04 15:11       ` Joshua Brindle
2006-12-04 15:24         ` Stephen Smalley
2006-12-04 18:13           ` Joshua Brindle
2006-12-04 18:49             ` Eric Paris
2006-12-04 19:39               ` Stephen Smalley
2006-12-04 20:06                 ` Karl MacMillan
2006-12-04 20:11                   ` Joshua Brindle
2006-12-04 20:15                     ` Karl MacMillan [this message]
2006-12-04 20:18                       ` Joshua Brindle
2006-12-04 20:25                         ` Karl MacMillan
2006-12-04 20:28                           ` Joshua Brindle
2006-12-04 20:25                             ` Stephen Smalley
2006-12-04 20:34                               ` Karl MacMillan
2006-12-04 20:44                                 ` Stephen Smalley
2006-12-04 21:05                                   ` Karl MacMillan
2006-12-05 13:31                                     ` Stephen Smalley
2006-12-05 13:59                                       ` Karl MacMillan
2006-12-04 20:33                             ` Karl MacMillan
2006-12-04 21:19                               ` Joshua Brindle
2006-12-04 21:34                                 ` Karl MacMillan
2006-12-04 23:20                                   ` Joshua Brindle
2006-12-05 13:41                                     ` Stephen Smalley
2006-12-05 13:33                                 ` 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=457481F8.5010907@mentalrootkit.com \
    --to=kmacmillan@mentalrootkit.com \
    --cc=eparis@parisplace.org \
    --cc=jbrindle@tresys.com \
    --cc=jmorris@redhat.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.