From: Joshua Brindle <method@manicmethod.com>
To: Eric Paris <eparis@parisplace.org>
Cc: "Christopher J. PeBenito" <cpebenito@tresys.com>,
Stephen Smalley <sds@tycho.nsa.gov>,
Paul Moore <paul.moore@hp.com>,
selinux@tycho.nsa.gov
Subject: Re: [PATCH] REFPOL: Add "rogue" Fedora packet class permissions
Date: Fri, 18 Jan 2008 11:52:38 -0500 [thread overview]
Message-ID: <4790D956.6050300@manicmethod.com> (raw)
In-Reply-To: <7e0fb38c0801180706s130ff8cbv769f91fe18789f36@mail.gmail.com>
Eric Paris wrote:
> On 1/18/08, Christopher J. PeBenito <cpebenito@tresys.com> wrote:
>
>> On Thu, 2008-01-17 at 14:33 -0500, Stephen Smalley wrote:
>>
>>> On Thu, 2008-01-17 at 14:13 -0500, Joshua Brindle wrote:
>>>
>>>> Paul Moore wrote:
>>>>
>>>>> At some point in the Fedora 6 timeframe the "flow_in" and "flow_out"
>>>>> permissions were added to the "packet" class, most likely as part of the
>>>>> ill-fated secid-reconciliation effort. Despite the fact that these permissions
>>>>> are not currently used they should be included in the Reference Policy as they
>>>>> are now a permanent fixture in Fedora and it is crucial that the FLASK
>>>>> defines be kept in sync.
>>>>>
>>>>> This patch needs to be applied before any other patches that affect the
>>>>> "packet" class, otherwise the resulting policy may not load.
>>>>>
>>>> This also points out how much of a bad idea it is to add object
>>>> class/perm definitions into distro policies before they are in
>>>> refpolicy, I hope that this will be avoided in the future.
>>>>
>> Definitely.
>>
>
> Dan and I are both well aware of this and I think we can all be
> certain it won't happen again.
>
>
I'm fine with drilling it in just to make sure ;)
>>> This all came up because akpm reported the failure on his FC6 test box
>>> with latest -mm.
>>>
>
> failure == kernel panic
>
>
>>> I suggested just using flow_in/flow_out instead of
>>> forward_in/forward_out for Paul's new controls so that we don't have any
>>> unused permissions, but Paul and Eric want the more precise names.
>>>
>> I strongly agree with Stephen's suggestion. Do we have a strategy for
>> eventually reclaiming these permissions if we don't reuse them right
>> now?
>>
>
> I'm willing to do the kernel work to support NULL names for these
> permissions and maybe in 5 years or so we will all feel comfortable
> reusing them (basically the same situation we are in for things like
> unused classes we carry around for PAX, we can't reclaim it till we
> can be sure everything that ever used it is dead). But labeled net is
> convoluted and difficult enough without even the slightest of
> misdirection of permission names. If down the road people search teh
> intarwebz on flow_in they are going to get back to all of venkat's old
> discussions of 'flow.' This isn't what we want.
>
>
I think we know the Pax object class isn't being used anymore. One thing
on our long list is to fix up the kernel to request object class and
perm values similarly to the work done to do that from userspace last
year. Once that is done we can hopefully do a wholesale cleaning of
unused values.
> I know it sucks and fedora screwed up on this one getting a little
> overzelous trying to stay ahead of the development game but at this
> point lets waste that 50 bytes of memory or whatever so down the road
> we don't have issues.
>
--
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.
prev parent reply other threads:[~2008-01-18 16:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-17 17:22 [PATCH] REFPOL: Add "rogue" Fedora packet class permissions Paul Moore
2008-01-17 17:30 ` Eric Paris
2008-01-17 19:13 ` Joshua Brindle
2008-01-17 19:23 ` Paul Moore
2008-01-17 19:33 ` Stephen Smalley
2008-01-18 13:32 ` Christopher J. PeBenito
2008-01-18 14:11 ` Paul Moore
2008-01-18 14:38 ` Christopher J. PeBenito
2008-01-19 3:44 ` Paul Moore
2008-01-18 15:06 ` Eric Paris
2008-01-18 16:52 ` Joshua Brindle [this message]
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=4790D956.6050300@manicmethod.com \
--to=method@manicmethod.com \
--cc=cpebenito@tresys.com \
--cc=eparis@parisplace.org \
--cc=paul.moore@hp.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.