From: Casey Schaufler <casey@schaufler-ca.com>
To: Paul Moore <pmoore@redhat.com>
Cc: netdev@vger.kernel.org, linux-security-module@vger.kernel.org,
selinux@tycho.nsa.gov, Andy King <acking@vmware.com>,
Gerd Hoffmann <kraxel@redhat.com>, Eric Paris <eparis@redhat.com>
Subject: Re: LSM stacking and the network access controls
Date: Wed, 27 Feb 2013 08:51:50 -0800 [thread overview]
Message-ID: <512E39A6.1000804@schaufler-ca.com> (raw)
In-Reply-To: <9802466.KDjcZ61qbX@sifl>
On 2/27/2013 8:43 AM, Paul Moore wrote:
> On Tuesday, February 26, 2013 03:12:31 PM Casey Schaufler wrote:
>> On 2/26/2013 1:21 PM, Paul Moore wrote:
>>> On Monday, February 25, 2013 03:06:14 PM Casey Schaufler wrote:
>>>> The set of LSMs, the order they are invoked, which LSM
>>>> uses /proc/.../attr/current and which LSM uses Netlabel,
>>>> XFRM and secmark are all determined by Kconfig. You can
>>>> specify a limited set of LSMs using security= at boot,
>>>> but not the networking configuration.
>>> That's unfortunate. I'm _really_ not in favor of that, I would much
>>> rather see the non-shared LSM functionality assigned at the same time as
>>> the stacking order. I'm not sure I'd NACK the current approach, or even\
>>> if anyone would care that I did, but that is how I'm currently leaning
>>> with this split (build vs runtime) selection.
>> I'm not against that approach. How would you see it working?
>>
>> The distro compiles in all the LSMs.
>> They specify that SELinux gets xfrm and secmark.
>> They specify the Smack gets Netlabel.
>> They tell (the new and improved) AppArmor to eschew networking.
>> They specify a boot order of "selinux,smack,apparmor,yama"
>> (They left off tomoyo for tax purposes).
>>
>> On the boot line, the user types "security=apparmor".
>>
>> What should happen?
> Okay, I misunderstood what was specified at boot time; I thought the stacking
> order could be defined at boot but based on your example I'm guessing the
> stacking order is defined at compile time and you can only enable/disable LSMs
> at boot?
Well, no. It looks as if I gave a poor example.
"security=apparmor,tomoyo,selinux"
is legitimate and indicates that AppArmor goes first,
then TOMOYO, then SELinux. No LSM gets NetLabel because
that was allocated to Smack. SELinux gets XFRM and secmark.
>>>> Tetsuo is lobbying for loadable security modules. I am
>>>> doing my best to leave everything in a state where some
>>>> soul braver than I might pick that up after I'm done.
>>>> I do not have any intention of supporting on the fly
>>>> or heuristically determined networking.
>>> Well, if that is the case I think the first-come-first-served approach to
>>> the non-shared functionality probably makes the most sense. I understand
>>> why it might not be ideal in ever situation but it is predictable.
>> Would you have the same opinion if SELinux were last, instead of first?
> Yes.
>
> In fact, considering the example above, and also assuming I'm understanding it
> correctly, I think I am more in favor of the first-come-first-served approach
> since you can enable/disable LSMs at boot. Imagine if you gave one LSM all
> the non-shared functionality but disabled it at boot in favor of another LSM
> which could make use of some of this functionality but was denied due to the
> compile time option. This seems much more useful to me.
>
>>>>>> I'm trying not to make too many architectural changes to the
>>>>>> code around the LSM mechanism itself. I don't see that as cost
>>>>>> effective or likely to be popular. If the implication of that is
>>>>>> that there are certain configurations that are unsupportable but
>>>>>> that have plausible alternatives I think it will do for phase I.
>>>>> That statement is vague enough that I can't really say yes or no to it,
>>>>> but I will stick by my previous comments about the network access
>>>>> controls.
>>>> Ah. I want to create a useful system. I want to create it
>>>> reasonably short order. I am willing to forgo supporting
>>>> some configuration options to reduce the project time. In
>>>> particular, I hope to avoid mucking up other people's code
>>>> as that is a sure fire way to bog a project down.
>>> Usefulness is paramount of course
>> Agreed
>>
>>> and quickness is nice,
>> If it drags on too long the boss gets cranky. And "labelled" NFSv4.2
>> gets done. And the list macros get reworked. And ....
>>
>>> but I do think it takes a back seat to "the right solution".
>> If I had two years and didn't have to worry about anyone else's
>> changes and weren't beholden to retaining some of the past's more
>> interesting design choices I'd be more concerned about "right" than
>> "good".
>>
>>> We're all going to have to live with this f-o-r-e-v-e-r,
>> Assuming it gets adopted. It will have to be good enough for that.
>> There is no guarantee on that.
>>
>>> or at least what will surely seem like it, so I'd much rather we take the
>>> time to make sure we beat out as much ugly as we can before it is merged.
>> I'm with you there. I just hope the ugly hasn't been lifting weights.
> February is "fitness month".
--
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:[~2013-02-27 16:51 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-22 22:33 AF_VSOCK and the LSMs Paul Moore
2013-02-22 23:00 ` Casey Schaufler
2013-02-23 0:45 ` Paul Moore
2013-02-23 23:43 ` Casey Schaufler
2013-02-25 16:55 ` Paul Moore
2013-02-25 18:02 ` Casey Schaufler
2013-02-25 21:05 ` Paul Moore
2013-02-25 23:06 ` Casey Schaufler
2013-02-26 21:21 ` LSM stacking and the network access controls (was: AF_VSOCK and the LSMs) Paul Moore
2013-02-26 23:12 ` LSM stacking and the network access controls Casey Schaufler
2013-02-27 16:43 ` Paul Moore
2013-02-27 16:51 ` Casey Schaufler [this message]
2013-02-27 17:31 ` Paul Moore
2013-02-27 17:40 ` Casey Schaufler
[not found] ` <888679886.3769933.1361573683299.JavaMail.root@vmware.com>
2013-02-23 0:27 ` AF_VSOCK and the LSMs Paul Moore
[not found] ` <512B12EA.1000003@redhat.com>
2013-02-25 15:06 ` Paul Moore
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=512E39A6.1000804@schaufler-ca.com \
--to=casey@schaufler-ca.com \
--cc=acking@vmware.com \
--cc=eparis@redhat.com \
--cc=kraxel@redhat.com \
--cc=linux-security-module@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pmoore@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).