All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joshua Brindle <method@manicmethod.com>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Eric Paris <eparis@redhat.com>,
	selinux@tycho.nsa.gov,
	Karl MacMillan <kmacmillan@mentalrootkit.com>
Subject: Re: Where to specific the handling of unknown kernel classes and perms
Date: Thu, 03 May 2007 09:20:03 -0400	[thread overview]
Message-ID: <4639E183.4080909@manicmethod.com> (raw)
In-Reply-To: <1178196394.3443.135.camel@moss-spartans.epoch.ncsc.mil>

Stephen Smalley wrote:
> On Wed, 2007-05-02 at 20:46 -0400, Joshua Brindle wrote:
>   
>> Eric Paris wrote:
>>     
>>> I just sent out a kernel patch with the tristate flag to change kernel
>>> handling of unknown classes and permissions.  The idea is that when the
>>> policy is created someone can set the flag to any of the three options
>>> (deny/reject/allow) and the kernel will act accordingly.  My problem is
>>> I don't understand the userspace tools which create policy.  I patched
>>> libsepol to support this new flag when it reads or writes a policydb,
>>> which allows me to edit my policy.21 by hand in hex and then call
>>> load_policy to test my kernel.  My problem now is that I don't know
>>> where a user should be specifying how they want the flags to be set.  To
>>> be perfectly honest after a bit of searching I'm not even sure where
>>> policy.21 gets created when I build a policy.
>>>
>>>   
>>>       
>> It should be setable in semanage.conf or by checkpolicy if building a 
>> monolithic policy.
>>     
>
> Hmm...actually, I would have argued that it should only be settable by
> checkpolicy/checkmodule, and always inherited from the base module in
> the link/expand case.  That way we can always know what the kernel
> behavior is by looking at the base module, vs. having to separately look
> at semanage.conf.  It is a tradeoff though in terms of analyzability vs.
> ease of customization
Even if it is propagated from the base policy I think it should be 
overridable in semanage.conf. Propagating it from base means we'll have 
to extend the policy server object model to cover it but that is no big 
deal. The reason semanage.conf would be nice is to change the behavior 
locally on RH systems without rebuilding the base policy.

--
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:[~2007-05-03 13:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-02 21:25 Where to specific the handling of unknown kernel classes and perms Eric Paris
2007-05-03  0:46 ` Joshua Brindle
2007-05-03 12:42   ` Karl MacMillan
2007-05-03 12:46   ` Stephen Smalley
2007-05-03 13:20     ` Joshua Brindle [this message]
2007-05-03 13:54       ` Stephen Smalley
2007-05-03 15:31         ` Joshua Brindle
2007-05-04 15:37           ` Daniel J Walsh
2007-05-04 16:15             ` Karl MacMillan
2007-05-04 17:19               ` Daniel J Walsh
2007-05-03  2:12 ` Joshua Brindle

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=4639E183.4080909@manicmethod.com \
    --to=method@manicmethod.com \
    --cc=eparis@redhat.com \
    --cc=kmacmillan@mentalrootkit.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.