Re: how to implement permissive domains + an old bug

[Daniel J Walsh <dwalsh@redhat.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christopher J. PeBenito wrote:
> On Mon, 2008-02-25 at 15:40 -0500, Joshua Brindle wrote:
>> Stephen Smalley wrote:
>>> On Mon, 2008-02-25 at 09:53 -0500, Joshua Brindle wrote:
>>>> Daniel J Walsh wrote:
>>>>> Stephen Smalley wrote:
>>>>>> On Fri, 2008-02-15 at 15:17 -0500, Joshua Brindle wrote:
>>>>>>> Stephen Smalley wrote:
>>>>>>>> Crazy idea:  Make "permissive" a special type attribute name, and
>>>>>>>> mark types that should be permissive with that attribute via
>>>>>>>> typeattribute. Then let the usual type attribute handling
>>>>>>>> propagate it throughout. 
>>>>>>>>
>>>>>>> Aaahhh! Here we got rid of those magic mls attributes and you
>>>>>>> want to add more :) 
>>>>>>>
>>>>>>> I'd much prefer a proper feature instead of special cased
>>>>>>> attribute names, just me though.
>>>>>> I'm not as convinced, so possibly others should chime in too.
>>>>>>
>>>>>> Type attributes are intended to indicate "properties" of types.  It
>>>>>> just happens that at present, the names and semantics of those
>>>>>> properties are entirely defined within the policy configuration.
>>>>>> But reserving some attribute names to have well-defined semantics
>>>>>> encoded in the policy engine itself seems a natural extension, and
>>>>>> we did do that in the original MLS implementation for trusted
>>>>>> subjects (and I didn't view that as necessarily a bad thing).
>>>>>>
>>>>>> Introducing a new language primitive each time we want to mark a
>>>>>> set of types for special handling by the policy engine logic seems
>>>>>> less clean to me, even aside from implementation aspects.
>>>>>>
>>>>>> It also makes Eric's life a lot simpler ;)  No need to modify
>>>>>> checkpolicy or the policy module logic at all.  A new kernel policy
>>>>>> version would still be required, but we would get a side benefit
>>>>>> from it in addition to permissive domains - preservation of type
>>>>>> attribute names in the kernel policy.
>>>>>>
>>>> I understand. I want to note though, that the TE part of the SS has
>>>> not had policy logic built into it, at least since I've been using
>>>> SELinux. The old hardcoded attributes were part of the hardcoded MLS
>>>> logic but we've even replaced that with a flexible system.
>>>>
>>>> I'm going to borrow a page from Chad's book here and say, during
>>>> SELinux tutorials and classes we reiterate "types and attributes have
>>>> no meaning other than what you give them in policy" say it over and
>>>> over til it sink in.. Oh yea, and there is this one that does (d'oh).
>>>>
>>>>>>> The last time we got rid of magic attributes with new contraints,
>>>>>>> maybe we need an 'unconstrain' :)
>>>>> I tend to agree.  I think we are making policy writing far to
>>>>> complex, with additional semantics.
>>>>>
>>>> Eh? When was the last time you saw a user have to modify a constraint
>>>> or mlsconstraint? Those additional semantics were to make the policy
>>>> more flexible, the users almost never interact with them.
>>> I think that's the point - here we want users to be able to
>>> make existing domains permissive or introduce permissive
>>> domains w/o having to write or modify a constraint at all.
>>>
>> It wouldn't require modifying a constraint any more than making
>> something mls privileged currently does.
>>
>>> Also, this notion of permissive domains goes beyond the
>>> existing security server interface.  As I recall, it doesn't
>>> just change what gets returned by security_compute_av() but
>>> rather is something that the AVC queries (based on SID) on
>>> the permission denied code path, like current enforcing mode.
>>>
>> Even better, that means we are using a magic attribute (part of the TE
>> system) to change the behavior of the avc. AFAIK nothing in the policy
>> really changes the avc behavior (right?).
>>
>> I don't want to stand in the way of this feature or anything, I'm just
>> concerned about doing it in a hacky way vs. something more elegant. I'd
>> like to hear others opinions, Chris? Todd?
> 
> I don't like the magic attributes as permissive is a mechanism option.
> It has no meaning in the policy, only in the enforcement.  I'd really
> prefer some other option in selinuxfs or a proc/pid/attr, but since that
> doesn't seem to be an option, I'd rather have a policy primitive.
> 
I would really rather just have it done.  As we continue to talk about
the feature 9 months after it was suggested. :^(

Fedora 9 Beta 1 Freeze is March 4th...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkfDLp4ACgkQrlYvE4MpobMKYwCgrCFKAhS95iqlZMcgE24VPVYQ
nW4Anj97+OgRj2WQK+tYduuFipku1OrG
=WLRn
-----END PGP SIGNATURE-----

--
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.