how to implement permissive domains + an old bug

how to implement permissive domains + an old bug

[Eric Paris]

So after many months of trying to avoid it Dan finally beat me into
looking at permissive domains.  I'm coming to the list to ask how people
feel the transfer of knowledge that a domain is permissive between the
policy and the kernel should be implemented.  (And to point out what I
think is a bug I found while trolling around the code today)

Old discussion of permissive domains.
http://marc.info/?l=selinux&m=118953810913436&w=2

The basic idea is that we want a domain in which a process can run
without any permission enforcement and without flooding the audit logs.
After much discussion I think everyone agreed with (or at least stopped
arguing against) a couple of things.

1) do this in policy (not selinuxfs)
2) have it act just like 'setenforce 0'

My question today is about #1.  How to implement?  Karl suggested
stealing a bit from the type_datum->primary field to indicate to the
kernel that a certain type was a permissive domain.  Can I do this?  I
guess this is a question for the setools group.  Do you make use of the
actual value stored in 'primary'?  The kernel does not.  Does anything
make use of the actual value outside of the tool chain?  Please say 'no'
and make this easier for me.

I want to throw away the 'primary' field all together in the final
binary policy and create a 'new' field called 'flags' in its place.
After my change flags would make use of 2 bits.

#define F_PRIMARY		0x00000001
#define F_PERMISSIVE		0x80000000
if (type_datum->old_primary)
	type_datum->flags = F_PRIMARY;
if (permissive domain)
    type_datum->flags |= F_PERMISSIVE

This only works if noone makes actual use of the value in ->primary.  If
someone makes use of the value in primary I can't really reuse that area
on disk and I think I'm going to have to bump the policy version and add
a whole new ->flags field on disk (I don't think pmoore's capability
stuff really helps).  Maybe the tools could just agree to ignore the
last bit?  To be honest I'm not personally terribly concerned about
setools backwards compatibility.  I'm really only thinking about
function backwards compatibility, so maybe the tools people would be ok
with me just userping a bit (but I'd much rather have a more clear
'flags' than 'primary + one bit stolen for some other random crap).  For
backwards compatibility I might have to bump the policy number even if
noone has a problem with me redefining the meaning of the ->primary
field, not sure yet haven't really wrapped my brain around it.  I think
there is a kernel bug which actually makes it possible to reuse the
field in my new way and maintain backwards kernel compatibility.

**The Bug**
In the binary policy on disk ->primary is a uint32_t but in the kernel
->primary is an unsigned char.  When we load policy we just have

typdatum->primary = le32_to_cpu(buf[2]);

So we are truncating to 8 bits.  I think that means that if the on disk
->primary value is greater than 0xFF but the lower 8 bits are all 0 we
are going to screw this up (maybe this is impossible, but I don't see
why looking at libsepol quickly).  Thanks to this bug though I think I
could use the 32nd bit of the on disk representation on old kernels and
they wouldn't even realize it.  New kernels could be made to pay
attention to that bit.  Backwards compatibility through bugs, I love it.
It also means I don't really want to fix this bug right now *smile*
**End bug**

There are other options on how to represent permissive domains in
policy, I think someone suggested

allow domain domain:process permissive

which would mean 2 passes through the avc for denials (at least the
first time for every sub/obj/class triple).  But this method got poo
poohd because of * and ^ usage.  Do we really use * and ^ any more?  I
honestly don't know.  It also makes all denials a little slower, but
shouldn't be noticeable on a system with a 'proper' policy.

What other ideas exist?  I'm looking for any ingenious ideas on how we
can transfer 'this is a permissive domain' from the policy into the
kernel.  What I really want is a way to do it being backwards compatible
and without bumping the policy version....

Please, thoughts and brilliance requested, I'll do the coding, just
point me in the direction you see brightest.  Can I redefine ->primary
to be ->flags?  Do I need to just make a new ->flags?  Should I go
through the avc twice to see if we are a permissive domain?  Is there a
better way to communicate this information from the policy into the
kernel?

-Eric


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

Re: how to implement permissive domains + an old bug

[Stephen Smalley]

On Fri, 2008-02-15 at 12:50 -0500, Eric Paris wrote:
> So after many months of trying to avoid it Dan finally beat me into
> looking at permissive domains.  I'm coming to the list to ask how people
> feel the transfer of knowledge that a domain is permissive between the
> policy and the kernel should be implemented.  (And to point out what I
> think is a bug I found while trolling around the code today)
> 
> Old discussion of permissive domains.
> http://marc.info/?l=selinux&m=118953810913436&w=2
> 
> The basic idea is that we want a domain in which a process can run
> without any permission enforcement and without flooding the audit logs.
> After much discussion I think everyone agreed with (or at least stopped
> arguing against) a couple of things.
> 
> 1) do this in policy (not selinuxfs)
> 2) have it act just like 'setenforce 0'
> 
> My question today is about #1.  How to implement?  Karl suggested
> stealing a bit from the type_datum->primary field to indicate to the
> kernel that a certain type was a permissive domain.  Can I do this?  I
> guess this is a question for the setools group.  Do you make use of the
> actual value stored in 'primary'?  The kernel does not.  Does anything
> make use of the actual value outside of the tool chain?  Please say 'no'
> and make this easier for me.
> 
> I want to throw away the 'primary' field all together in the final
> binary policy and create a 'new' field called 'flags' in its place.
> After my change flags would make use of 2 bits.
> 
> #define F_PRIMARY		0x00000001
> #define F_PERMISSIVE		0x80000000
> if (type_datum->old_primary)
> 	type_datum->flags = F_PRIMARY;
> if (permissive domain)
>     type_datum->flags |= F_PERMISSIVE
> 
> This only works if noone makes actual use of the value in ->primary.  If
> someone makes use of the value in primary I can't really reuse that area
> on disk and I think I'm going to have to bump the policy version and add
> a whole new ->flags field on disk (I don't think pmoore's capability
> stuff really helps).  Maybe the tools could just agree to ignore the
> last bit?  To be honest I'm not personally terribly concerned about
> setools backwards compatibility.  I'm really only thinking about
> function backwards compatibility, so maybe the tools people would be ok
> with me just userping a bit (but I'd much rather have a more clear
> 'flags' than 'primary + one bit stolen for some other random crap).  For
> backwards compatibility I might have to bump the policy number even if
> noone has a problem with me redefining the meaning of the ->primary
> field, not sure yet haven't really wrapped my brain around it.  I think
> there is a kernel bug which actually makes it possible to reuse the
> field in my new way and maintain backwards kernel compatibility.
> 
> **The Bug**
> In the binary policy on disk ->primary is a uint32_t but in the kernel
> ->primary is an unsigned char.  When we load policy we just have
> 
> typdatum->primary = le32_to_cpu(buf[2]);
> 
> So we are truncating to 8 bits.  I think that means that if the on disk
> ->primary value is greater than 0xFF but the lower 8 bits are all 0 we
> are going to screw this up (maybe this is impossible, but I don't see
> why looking at libsepol quickly).  Thanks to this bug though I think I
> could use the 32nd bit of the on disk representation on old kernels and
> they wouldn't even realize it.  New kernels could be made to pay
> attention to that bit.  Backwards compatibility through bugs, I love it.
> It also means I don't really want to fix this bug right now *smile*
> **End bug**

Kernel policy representation only uses ->primary as a boolean flag (is
it a primary name or an alias, with the type index value in ->value
regardless).  Modular policy introduced the notion of using it to store
the primary type index for aliases (when ->flavor == TYPE_ALIAS).  By
the time we reach kernel policy (after expansion), it should only be a
boolean again.

> There are other options on how to represent permissive domains in
> policy, I think someone suggested
> 
> allow domain domain:process permissive
> 
> which would mean 2 passes through the avc for denials (at least the
> first time for every sub/obj/class triple).  But this method got poo
> poohd because of * and ^ usage.  Do we really use * and ^ any more?  I
> honestly don't know.  It also makes all denials a little slower, but
> shouldn't be noticeable on a system with a 'proper' policy.
> 
> What other ideas exist?  I'm looking for any ingenious ideas on how we
> can transfer 'this is a permissive domain' from the policy into the
> kernel.  What I really want is a way to do it being backwards compatible
> and without bumping the policy version....
> 
> Please, thoughts and brilliance requested, I'll do the coding, just
> point me in the direction you see brightest.  Can I redefine ->primary
> to be ->flags?  Do I need to just make a new ->flags?  Should I go
> through the avc twice to see if we are a permissive domain?  Is there a
> better way to communicate this information from the policy into the
> kernel?
> 
> -Eric
-- 
Stephen Smalley
National Security Agency


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

RE: how to implement permissive domains + an old bug

[Joshua Brindle]

Stephen Smalley wrote:
> On Fri, 2008-02-15 at 12:50 -0500, Eric Paris wrote:
>> So after many months of trying to avoid it Dan finally beat me into
>> looking at permissive domains.  I'm coming to the list to ask how
>> people feel the transfer of knowledge that a domain is permissive
>> between the policy and the kernel should be implemented.  (And to
>> point out what I think is a bug I found while trolling around the
>> code today) 
>> 
>> Old discussion of permissive domains.
>> http://marc.info/?l=selinux&m=118953810913436&w=2
>> 
>> The basic idea is that we want a domain in which a process can run
>> without any permission enforcement and without flooding the audit
>> logs. After much discussion I think everyone agreed with (or at least
>> stopped arguing against) a couple of things.
>> 
>> 1) do this in policy (not selinuxfs)
>> 2) have it act just like 'setenforce 0'
>> 
>> My question today is about #1.  How to implement?  Karl suggested
>> stealing a bit from the type_datum->primary field to indicate to the
>> kernel that a certain type was a permissive domain.  Can I do this? 
>> I guess this is a question for the setools group.  Do you make use of
>> the actual value stored in 'primary'?  The kernel does not.  Does
>> anything make use of the actual value outside of the tool chain? 
>> Please say 'no' and make this easier for me. 
>> 
>> I want to throw away the 'primary' field all together in the final
>> binary policy and create a 'new' field called 'flags' in its place.
>> After my change flags would make use of 2 bits.
>> 
>> #define F_PRIMARY		0x00000001
>> #define F_PERMISSIVE		0x80000000
>> if (type_datum->old_primary)
>> 	type_datum->flags = F_PRIMARY;
>> if (permissive domain)
>>     type_datum->flags |= F_PERMISSIVE
>> 
>> This only works if noone makes actual use of the value in ->primary.
>> If someone makes use of the value in primary I can't really reuse
>> that area on disk and I think I'm going to have to bump the policy
>> version and add a whole new ->flags field on disk (I don't think
>> pmoore's capability stuff really helps).  Maybe the tools could just
>> agree to ignore the last bit?  To be honest I'm not personally
>> terribly concerned about setools backwards compatibility.  I'm
>> really only thinking about function backwards compatibility, so
>> maybe the tools people would be ok with me just userping a bit (but
>> I'd much rather have a more clear 'flags' than 'primary + one bit
>> stolen for some other random crap).  For backwards compatibility I
>> might have to bump the policy number even if noone has a problem
>> with me redefining the meaning of the ->primary field, not sure yet
>> haven't really wrapped my brain around it.  I think there is a
>> kernel bug which actually makes it possible to reuse the field in my
>> new way and maintain 
> backwards kernel compatibility.
>> 
>> **The Bug**
>> In the binary policy on disk ->primary is a uint32_t but in the
>> kernel ->primary is an unsigned char.  When we load policy we just
>> have 
>> 
>> typdatum->primary = le32_to_cpu(buf[2]);
>> 
>> So we are truncating to 8 bits.  I think that means that if the on
>> disk ->primary value is greater than 0xFF but the lower 8 bits are
>> all 0 we are going to screw this up (maybe this is impossible, but I
>> don't see why looking at libsepol quickly).  Thanks to this bug
>> though I think I could use the 32nd bit of the on disk
>> representation on old kernels and they wouldn't even realize it. 
>> New kernels could be made to pay attention to that bit.  Backwards
>> compatibility through bugs, I love it. It also means I don't really
>> want to fix this bug right now *smile* **End bug**
> 
> Kernel policy representation only uses ->primary as a boolean
> flag (is it a primary name or an alias, with the type index
> value in ->value regardless).  Modular policy introduced the
> notion of using it to store the primary type index for
> aliases (when ->flavor == TYPE_ALIAS).  By the time we reach
> kernel policy (after expansion), it should only be a boolean again.
> 

The problem is how to propagate the permissive bit through the module
format if we choose to do it that way. Foruntately the type id's can
only be 16 bit per the version 20 avtab changes but I'm still concerned
about changing the format without actually telling anything we are
changing it (via a policy vers bump).

>> There are other options on how to represent permissive domains in
>> policy, I think someone suggested
>> 
>> allow domain domain:process permissive
>> 
>> which would mean 2 passes through the avc for denials (at least the
>> first time for every sub/obj/class triple).  But this method got poo
>> poohd because of * and ^ usage.  Do we really use * and ^ any more? 
>> I honestly don't know.  It also makes all denials a little slower,
>> but shouldn't be noticeable on a system with a 'proper' policy.
>> 
>> What other ideas exist?  I'm looking for any ingenious ideas on how
>> we can transfer 'this is a permissive domain' from the policy into
>> the kernel.  What I really want is a way to do it being backwards
>> compatible and without bumping the policy version....
>> 
>> Please, thoughts and brilliance requested, I'll do the coding, just
>> point me in the direction you see brightest.  Can I redefine
>> ->primary to be ->flags?  Do I need to just make a new ->flags? 
>> Should I go through the avc twice to see if we are a permissive
>> domain? 
>  Is there
>> a better way to communicate this information from the policy into
>> the kernel? 
>> 
>> -Eric



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

RE: how to implement permissive domains + an old bug

[Stephen Smalley]

On Fri, 2008-02-15 at 13:35 -0500, Joshua Brindle wrote:
> Stephen Smalley wrote:
> > On Fri, 2008-02-15 at 12:50 -0500, Eric Paris wrote:
> >> So after many months of trying to avoid it Dan finally beat me into
> >> looking at permissive domains.  I'm coming to the list to ask how
> >> people feel the transfer of knowledge that a domain is permissive
> >> between the policy and the kernel should be implemented.  (And to
> >> point out what I think is a bug I found while trolling around the
> >> code today) 
> >> 
> >> Old discussion of permissive domains.
> >> http://marc.info/?l=selinux&m=118953810913436&w=2
> >> 
> >> The basic idea is that we want a domain in which a process can run
> >> without any permission enforcement and without flooding the audit
> >> logs. After much discussion I think everyone agreed with (or at least
> >> stopped arguing against) a couple of things.
> >> 
> >> 1) do this in policy (not selinuxfs)
> >> 2) have it act just like 'setenforce 0'
> >> 
> >> My question today is about #1.  How to implement?  Karl suggested
> >> stealing a bit from the type_datum->primary field to indicate to the
> >> kernel that a certain type was a permissive domain.  Can I do this? 
> >> I guess this is a question for the setools group.  Do you make use of
> >> the actual value stored in 'primary'?  The kernel does not.  Does
> >> anything make use of the actual value outside of the tool chain? 
> >> Please say 'no' and make this easier for me. 
> >> 
> >> I want to throw away the 'primary' field all together in the final
> >> binary policy and create a 'new' field called 'flags' in its place.
> >> After my change flags would make use of 2 bits.
> >> 
> >> #define F_PRIMARY		0x00000001
> >> #define F_PERMISSIVE		0x80000000
> >> if (type_datum->old_primary)
> >> 	type_datum->flags = F_PRIMARY;
> >> if (permissive domain)
> >>     type_datum->flags |= F_PERMISSIVE
> >> 
> >> This only works if noone makes actual use of the value in ->primary.
> >> If someone makes use of the value in primary I can't really reuse
> >> that area on disk and I think I'm going to have to bump the policy
> >> version and add a whole new ->flags field on disk (I don't think
> >> pmoore's capability stuff really helps).  Maybe the tools could just
> >> agree to ignore the last bit?  To be honest I'm not personally
> >> terribly concerned about setools backwards compatibility.  I'm
> >> really only thinking about function backwards compatibility, so
> >> maybe the tools people would be ok with me just userping a bit (but
> >> I'd much rather have a more clear 'flags' than 'primary + one bit
> >> stolen for some other random crap).  For backwards compatibility I
> >> might have to bump the policy number even if noone has a problem
> >> with me redefining the meaning of the ->primary field, not sure yet
> >> haven't really wrapped my brain around it.  I think there is a
> >> kernel bug which actually makes it possible to reuse the field in my
> >> new way and maintain 
> > backwards kernel compatibility.
> >> 
> >> **The Bug**
> >> In the binary policy on disk ->primary is a uint32_t but in the
> >> kernel ->primary is an unsigned char.  When we load policy we just
> >> have 
> >> 
> >> typdatum->primary = le32_to_cpu(buf[2]);
> >> 
> >> So we are truncating to 8 bits.  I think that means that if the on
> >> disk ->primary value is greater than 0xFF but the lower 8 bits are
> >> all 0 we are going to screw this up (maybe this is impossible, but I
> >> don't see why looking at libsepol quickly).  Thanks to this bug
> >> though I think I could use the 32nd bit of the on disk
> >> representation on old kernels and they wouldn't even realize it. 
> >> New kernels could be made to pay attention to that bit.  Backwards
> >> compatibility through bugs, I love it. It also means I don't really
> >> want to fix this bug right now *smile* **End bug**
> > 
> > Kernel policy representation only uses ->primary as a boolean
> > flag (is it a primary name or an alias, with the type index
> > value in ->value regardless).  Modular policy introduced the
> > notion of using it to store the primary type index for
> > aliases (when ->flavor == TYPE_ALIAS).  By the time we reach
> > kernel policy (after expansion), it should only be a boolean again.
> > 
> 
> The problem is how to propagate the permissive bit through the module
> format if we choose to do it that way. Foruntately the type id's can
> only be 16 bit per the version 20 avtab changes but I'm still concerned
> about changing the format without actually telling anything we are
> changing it (via a policy vers bump).

Yes, just explaining why it isn't a bug per se.

You not only have to propagate it through the module format but you have
to make sure that it propagates from type aliases to the primary datums
so that final primary datum has it set.

And whereas the kernel will ignore it, libsepol policydb_read won't,
even for the kernel policy (and that can happen upon downgrade or
boolean preservation or in the setlocaldefs case).

So, I think introducing a new version is likely required.  And in that
case, you might as well roll in other desired changes simultaneously.

> >> There are other options on how to represent permissive domains in
> >> policy, I think someone suggested
> >> 
> >> allow domain domain:process permissive
> >> 
> >> which would mean 2 passes through the avc for denials (at least the
> >> first time for every sub/obj/class triple).  But this method got poo
> >> poohd because of * and ^ usage.  Do we really use * and ^ any more? 
> >> I honestly don't know.  It also makes all denials a little slower,
> >> but shouldn't be noticeable on a system with a 'proper' policy.
> >> 
> >> What other ideas exist?  I'm looking for any ingenious ideas on how
> >> we can transfer 'this is a permissive domain' from the policy into
> >> the kernel.  What I really want is a way to do it being backwards
> >> compatible and without bumping the policy version....
> >> 
> >> Please, thoughts and brilliance requested, I'll do the coding, just
> >> point me in the direction you see brightest.  Can I redefine
> >> ->primary to be ->flags?  Do I need to just make a new ->flags? 
> >> Should I go through the avc twice to see if we are a permissive
> >> domain? 
> >  Is there
> >> a better way to communicate this information from the policy into
> >> the kernel? 
> >> 
> >> -Eric
> 
> 
> 
> --
> 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.
-- 
Stephen Smalley
National Security Agency


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

RE: how to implement permissive domains + an old bug

[Eric Paris]

On Fri, 2008-02-15 at 13:57 -0500, Stephen Smalley wrote:
> On Fri, 2008-02-15 at 13:35 -0500, Joshua Brindle wrote:
> > Stephen Smalley wrote:
> > > On Fri, 2008-02-15 at 12:50 -0500, Eric Paris wrote:
> > >> So after many months of trying to avoid it Dan finally beat me into
> > >> looking at permissive domains.  I'm coming to the list to ask how
> > >> people feel the transfer of knowledge that a domain is permissive
> > >> between the policy and the kernel should be implemented.  (And to
> > >> point out what I think is a bug I found while trolling around the
> > >> code today) 
> > >> 
> > >> Old discussion of permissive domains.
> > >> http://marc.info/?l=selinux&m=118953810913436&w=2
> > >> 
> > >> The basic idea is that we want a domain in which a process can run
> > >> without any permission enforcement and without flooding the audit
> > >> logs. After much discussion I think everyone agreed with (or at least
> > >> stopped arguing against) a couple of things.
> > >> 
> > >> 1) do this in policy (not selinuxfs)
> > >> 2) have it act just like 'setenforce 0'
> > >> 
> > >> My question today is about #1.  How to implement?  Karl suggested
> > >> stealing a bit from the type_datum->primary field to indicate to the
> > >> kernel that a certain type was a permissive domain.  Can I do this? 
> > >> I guess this is a question for the setools group.  Do you make use of
> > >> the actual value stored in 'primary'?  The kernel does not.  Does
> > >> anything make use of the actual value outside of the tool chain? 
> > >> Please say 'no' and make this easier for me. 
> > >> 
> > >> I want to throw away the 'primary' field all together in the final
> > >> binary policy and create a 'new' field called 'flags' in its place.
> > >> After my change flags would make use of 2 bits.
> > >> 
> > >> #define F_PRIMARY		0x00000001
> > >> #define F_PERMISSIVE		0x80000000
> > >> if (type_datum->old_primary)
> > >> 	type_datum->flags = F_PRIMARY;
> > >> if (permissive domain)
> > >>     type_datum->flags |= F_PERMISSIVE
> > >> 
> > >> This only works if noone makes actual use of the value in ->primary.
> > >> If someone makes use of the value in primary I can't really reuse
> > >> that area on disk and I think I'm going to have to bump the policy
> > >> version and add a whole new ->flags field on disk (I don't think
> > >> pmoore's capability stuff really helps).  Maybe the tools could just
> > >> agree to ignore the last bit?  To be honest I'm not personally
> > >> terribly concerned about setools backwards compatibility.  I'm
> > >> really only thinking about function backwards compatibility, so
> > >> maybe the tools people would be ok with me just userping a bit (but
> > >> I'd much rather have a more clear 'flags' than 'primary + one bit
> > >> stolen for some other random crap).  For backwards compatibility I
> > >> might have to bump the policy number even if noone has a problem
> > >> with me redefining the meaning of the ->primary field, not sure yet
> > >> haven't really wrapped my brain around it.  I think there is a
> > >> kernel bug which actually makes it possible to reuse the field in my
> > >> new way and maintain 
> > > backwards kernel compatibility.
> > >> 
> > >> **The Bug**
> > >> In the binary policy on disk ->primary is a uint32_t but in the
> > >> kernel ->primary is an unsigned char.  When we load policy we just
> > >> have 
> > >> 
> > >> typdatum->primary = le32_to_cpu(buf[2]);
> > >> 
> > >> So we are truncating to 8 bits.  I think that means that if the on
> > >> disk ->primary value is greater than 0xFF but the lower 8 bits are
> > >> all 0 we are going to screw this up (maybe this is impossible, but I
> > >> don't see why looking at libsepol quickly).  Thanks to this bug
> > >> though I think I could use the 32nd bit of the on disk
> > >> representation on old kernels and they wouldn't even realize it. 
> > >> New kernels could be made to pay attention to that bit.  Backwards
> > >> compatibility through bugs, I love it. It also means I don't really
> > >> want to fix this bug right now *smile* **End bug**
> > > 
> > > Kernel policy representation only uses ->primary as a boolean
> > > flag (is it a primary name or an alias, with the type index
> > > value in ->value regardless).  Modular policy introduced the
> > > notion of using it to store the primary type index for
> > > aliases (when ->flavor == TYPE_ALIAS).  By the time we reach
> > > kernel policy (after expansion), it should only be a boolean again.

I guess this being done in src/expand.c::type_copy_callback().

All my thought is for nothing though.  Somehow in the language we have
to represent permissive domains.  That in and of itself requires a
version bump doesn't it?  Drat.

So what format do we want to go with?

permissive httpd_t;

anyone got anything better?

So with the policy version bump should I add a new field, ->flags to the
on disk type_datum represenation?  Should I instead just rename
->primary to ->flags and teach libsepol to mask off the flag?  I don't
know the toolchain well enough to know if we ever write more than a
boolean to disk in ->primary.  Guess that's what I'll look for now but
first glance tells me I might as well use another 32 bits on disk since
it seems as though we have such disperate usage of primary for
POLICY_KERNEL vs everything else.

-Eric

-Eric


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

RE: how to implement permissive domains + an old bug

[Stephen Smalley]

On Fri, 2008-02-15 at 14:43 -0500, Eric Paris wrote:
> On Fri, 2008-02-15 at 13:57 -0500, Stephen Smalley wrote:
> > On Fri, 2008-02-15 at 13:35 -0500, Joshua Brindle wrote:
> > > Stephen Smalley wrote:
> > > > On Fri, 2008-02-15 at 12:50 -0500, Eric Paris wrote:
> > > >> So after many months of trying to avoid it Dan finally beat me into
> > > >> looking at permissive domains.  I'm coming to the list to ask how
> > > >> people feel the transfer of knowledge that a domain is permissive
> > > >> between the policy and the kernel should be implemented.  (And to
> > > >> point out what I think is a bug I found while trolling around the
> > > >> code today) 
> > > >> 
> > > >> Old discussion of permissive domains.
> > > >> http://marc.info/?l=selinux&m=118953810913436&w=2
> > > >> 
> > > >> The basic idea is that we want a domain in which a process can run
> > > >> without any permission enforcement and without flooding the audit
> > > >> logs. After much discussion I think everyone agreed with (or at least
> > > >> stopped arguing against) a couple of things.
> > > >> 
> > > >> 1) do this in policy (not selinuxfs)
> > > >> 2) have it act just like 'setenforce 0'
> > > >> 
> > > >> My question today is about #1.  How to implement?  Karl suggested
> > > >> stealing a bit from the type_datum->primary field to indicate to the
> > > >> kernel that a certain type was a permissive domain.  Can I do this? 
> > > >> I guess this is a question for the setools group.  Do you make use of
> > > >> the actual value stored in 'primary'?  The kernel does not.  Does
> > > >> anything make use of the actual value outside of the tool chain? 
> > > >> Please say 'no' and make this easier for me. 
> > > >> 
> > > >> I want to throw away the 'primary' field all together in the final
> > > >> binary policy and create a 'new' field called 'flags' in its place.
> > > >> After my change flags would make use of 2 bits.
> > > >> 
> > > >> #define F_PRIMARY		0x00000001
> > > >> #define F_PERMISSIVE		0x80000000
> > > >> if (type_datum->old_primary)
> > > >> 	type_datum->flags = F_PRIMARY;
> > > >> if (permissive domain)
> > > >>     type_datum->flags |= F_PERMISSIVE
> > > >> 
> > > >> This only works if noone makes actual use of the value in ->primary.
> > > >> If someone makes use of the value in primary I can't really reuse
> > > >> that area on disk and I think I'm going to have to bump the policy
> > > >> version and add a whole new ->flags field on disk (I don't think
> > > >> pmoore's capability stuff really helps).  Maybe the tools could just
> > > >> agree to ignore the last bit?  To be honest I'm not personally
> > > >> terribly concerned about setools backwards compatibility.  I'm
> > > >> really only thinking about function backwards compatibility, so
> > > >> maybe the tools people would be ok with me just userping a bit (but
> > > >> I'd much rather have a more clear 'flags' than 'primary + one bit
> > > >> stolen for some other random crap).  For backwards compatibility I
> > > >> might have to bump the policy number even if noone has a problem
> > > >> with me redefining the meaning of the ->primary field, not sure yet
> > > >> haven't really wrapped my brain around it.  I think there is a
> > > >> kernel bug which actually makes it possible to reuse the field in my
> > > >> new way and maintain 
> > > > backwards kernel compatibility.
> > > >> 
> > > >> **The Bug**
> > > >> In the binary policy on disk ->primary is a uint32_t but in the
> > > >> kernel ->primary is an unsigned char.  When we load policy we just
> > > >> have 
> > > >> 
> > > >> typdatum->primary = le32_to_cpu(buf[2]);
> > > >> 
> > > >> So we are truncating to 8 bits.  I think that means that if the on
> > > >> disk ->primary value is greater than 0xFF but the lower 8 bits are
> > > >> all 0 we are going to screw this up (maybe this is impossible, but I
> > > >> don't see why looking at libsepol quickly).  Thanks to this bug
> > > >> though I think I could use the 32nd bit of the on disk
> > > >> representation on old kernels and they wouldn't even realize it. 
> > > >> New kernels could be made to pay attention to that bit.  Backwards
> > > >> compatibility through bugs, I love it. It also means I don't really
> > > >> want to fix this bug right now *smile* **End bug**
> > > > 
> > > > Kernel policy representation only uses ->primary as a boolean
> > > > flag (is it a primary name or an alias, with the type index
> > > > value in ->value regardless).  Modular policy introduced the
> > > > notion of using it to store the primary type index for
> > > > aliases (when ->flavor == TYPE_ALIAS).  By the time we reach
> > > > kernel policy (after expansion), it should only be a boolean again.
> 
> I guess this being done in src/expand.c::type_copy_callback().
> 
> All my thought is for nothing though.  Somehow in the language we have
> to represent permissive domains.  That in and of itself requires a
> version bump doesn't it?  Drat.
> 
> So what format do we want to go with?
> 
> permissive httpd_t;
> 
> anyone got anything better?
> 
> So with the policy version bump should I add a new field, ->flags to the
> on disk type_datum represenation?  Should I instead just rename
> ->primary to ->flags and teach libsepol to mask off the flag?  I don't
> know the toolchain well enough to know if we ever write more than a
> boolean to disk in ->primary.  Guess that's what I'll look for now but
> first glance tells me I might as well use another 32 bits on disk since
> it seems as though we have such disperate usage of primary for
> POLICY_KERNEL vs everything else.

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.

Only issue is that we loose attribute names in the kernel at present
(expand strips them from the types symtab).  Which we should probably
change - I'll concede it was a mistake to omit them when I started
keeping attributes in rules in policy.20.  That would let the kernel
then look up "permissive" and get the set of types that should be
handled that way.  That's a format change though for the kernel, even if
module format is unaffected.

That would also have a side benefit for tools, as they could finally get
attribute name info from kernel policy.  setools would like that, and
audit2why could use it too (to identify what attribute would allow a
constraint violation to pass).

-- 
Stephen Smalley
National Security Agency


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

RE: how to implement permissive domains + an old bug

[Stephen Smalley]

On Fri, 2008-02-15 at 14:54 -0500, Stephen Smalley wrote:
> On Fri, 2008-02-15 at 14:43 -0500, Eric Paris wrote:
> > On Fri, 2008-02-15 at 13:57 -0500, Stephen Smalley wrote:
> > > On Fri, 2008-02-15 at 13:35 -0500, Joshua Brindle wrote:
> > > > Stephen Smalley wrote:
> > > > > On Fri, 2008-02-15 at 12:50 -0500, Eric Paris wrote:
> > > > >> So after many months of trying to avoid it Dan finally beat me into
> > > > >> looking at permissive domains.  I'm coming to the list to ask how
> > > > >> people feel the transfer of knowledge that a domain is permissive
> > > > >> between the policy and the kernel should be implemented.  (And to
> > > > >> point out what I think is a bug I found while trolling around the
> > > > >> code today) 
> > > > >> 
> > > > >> Old discussion of permissive domains.
> > > > >> http://marc.info/?l=selinux&m=118953810913436&w=2
> > > > >> 
> > > > >> The basic idea is that we want a domain in which a process can run
> > > > >> without any permission enforcement and without flooding the audit
> > > > >> logs. After much discussion I think everyone agreed with (or at least
> > > > >> stopped arguing against) a couple of things.
> > > > >> 
> > > > >> 1) do this in policy (not selinuxfs)
> > > > >> 2) have it act just like 'setenforce 0'
> > > > >> 
> > > > >> My question today is about #1.  How to implement?  Karl suggested
> > > > >> stealing a bit from the type_datum->primary field to indicate to the
> > > > >> kernel that a certain type was a permissive domain.  Can I do this? 
> > > > >> I guess this is a question for the setools group.  Do you make use of
> > > > >> the actual value stored in 'primary'?  The kernel does not.  Does
> > > > >> anything make use of the actual value outside of the tool chain? 
> > > > >> Please say 'no' and make this easier for me. 
> > > > >> 
> > > > >> I want to throw away the 'primary' field all together in the final
> > > > >> binary policy and create a 'new' field called 'flags' in its place.
> > > > >> After my change flags would make use of 2 bits.
> > > > >> 
> > > > >> #define F_PRIMARY		0x00000001
> > > > >> #define F_PERMISSIVE		0x80000000
> > > > >> if (type_datum->old_primary)
> > > > >> 	type_datum->flags = F_PRIMARY;
> > > > >> if (permissive domain)
> > > > >>     type_datum->flags |= F_PERMISSIVE
> > > > >> 
> > > > >> This only works if noone makes actual use of the value in ->primary.
> > > > >> If someone makes use of the value in primary I can't really reuse
> > > > >> that area on disk and I think I'm going to have to bump the policy
> > > > >> version and add a whole new ->flags field on disk (I don't think
> > > > >> pmoore's capability stuff really helps).  Maybe the tools could just
> > > > >> agree to ignore the last bit?  To be honest I'm not personally
> > > > >> terribly concerned about setools backwards compatibility.  I'm
> > > > >> really only thinking about function backwards compatibility, so
> > > > >> maybe the tools people would be ok with me just userping a bit (but
> > > > >> I'd much rather have a more clear 'flags' than 'primary + one bit
> > > > >> stolen for some other random crap).  For backwards compatibility I
> > > > >> might have to bump the policy number even if noone has a problem
> > > > >> with me redefining the meaning of the ->primary field, not sure yet
> > > > >> haven't really wrapped my brain around it.  I think there is a
> > > > >> kernel bug which actually makes it possible to reuse the field in my
> > > > >> new way and maintain 
> > > > > backwards kernel compatibility.
> > > > >> 
> > > > >> **The Bug**
> > > > >> In the binary policy on disk ->primary is a uint32_t but in the
> > > > >> kernel ->primary is an unsigned char.  When we load policy we just
> > > > >> have 
> > > > >> 
> > > > >> typdatum->primary = le32_to_cpu(buf[2]);
> > > > >> 
> > > > >> So we are truncating to 8 bits.  I think that means that if the on
> > > > >> disk ->primary value is greater than 0xFF but the lower 8 bits are
> > > > >> all 0 we are going to screw this up (maybe this is impossible, but I
> > > > >> don't see why looking at libsepol quickly).  Thanks to this bug
> > > > >> though I think I could use the 32nd bit of the on disk
> > > > >> representation on old kernels and they wouldn't even realize it. 
> > > > >> New kernels could be made to pay attention to that bit.  Backwards
> > > > >> compatibility through bugs, I love it. It also means I don't really
> > > > >> want to fix this bug right now *smile* **End bug**
> > > > > 
> > > > > Kernel policy representation only uses ->primary as a boolean
> > > > > flag (is it a primary name or an alias, with the type index
> > > > > value in ->value regardless).  Modular policy introduced the
> > > > > notion of using it to store the primary type index for
> > > > > aliases (when ->flavor == TYPE_ALIAS).  By the time we reach
> > > > > kernel policy (after expansion), it should only be a boolean again.
> > 
> > I guess this being done in src/expand.c::type_copy_callback().
> > 
> > All my thought is for nothing though.  Somehow in the language we have
> > to represent permissive domains.  That in and of itself requires a
> > version bump doesn't it?  Drat.
> > 
> > So what format do we want to go with?
> > 
> > permissive httpd_t;
> > 
> > anyone got anything better?
> > 
> > So with the policy version bump should I add a new field, ->flags to the
> > on disk type_datum represenation?  Should I instead just rename
> > ->primary to ->flags and teach libsepol to mask off the flag?  I don't
> > know the toolchain well enough to know if we ever write more than a
> > boolean to disk in ->primary.  Guess that's what I'll look for now but
> > first glance tells me I might as well use another 32 bits on disk since
> > it seems as though we have such disperate usage of primary for
> > POLICY_KERNEL vs everything else.
> 
> 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.
> 
> Only issue is that we loose attribute names in the kernel at present
> (expand strips them from the types symtab).  Which we should probably
> change - I'll concede it was a mistake to omit them when I started
> keeping attributes in rules in policy.20.  That would let the kernel
> then look up "permissive" and get the set of types that should be
> handled that way.  That's a format change though for the kernel, even if
> module format is unaffected.

Or if you want to go the minimally invasive route, you could just add a
single ebitmap at the end of the policy image, and copy the types
ebitmap from the "permissive" type datum before expand strips the
attribute entries.  That is how the old mlstrustedreader/writer/object
attributes used to be handled in the pre-TCS MLS implementation.  Still
a format change for the kernel though.

> That would also have a side benefit for tools, as they could finally get
> attribute name info from kernel policy.  setools would like that, and
> audit2why could use it too (to identify what attribute would allow a
> constraint violation to pass).
> 
-- 
Stephen Smalley
National Security Agency


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

RE: how to implement permissive domains + an old bug

[Joshua Brindle]

Stephen Smalley wrote:
> On Fri, 2008-02-15 at 14:43 -0500, Eric Paris wrote:
>> On Fri, 2008-02-15 at 13:57 -0500, Stephen Smalley wrote:
>>> On Fri, 2008-02-15 at 13:35 -0500, Joshua Brindle wrote:
>>>> Stephen Smalley wrote:
>>>>> On Fri, 2008-02-15 at 12:50 -0500, Eric Paris wrote:
>>>>>> So after many months of trying to avoid it Dan finally beat me
>>>>>> into looking at permissive domains.  I'm coming to the list to
>>>>>> ask how people feel the transfer of knowledge that a domain is
>>>>>> permissive between the policy and the kernel should be
>>>>>> implemented.  (And to point out what I think is a bug I found
>>>>>> while trolling around the code today)
>>>>>> 
>>>>>> Old discussion of permissive domains.
>>>>>> http://marc.info/?l=selinux&m=118953810913436&w=2
>>>>>> 
>>>>>> The basic idea is that we want a domain in which a process can
>>>>>> run without any permission enforcement and without flooding the
>>>>>> audit logs. After much discussion I think everyone agreed with
>>>>>> (or at least stopped arguing against) a couple of things.
>>>>>> 
>>>>>> 1) do this in policy (not selinuxfs)
>>>>>> 2) have it act just like 'setenforce 0'
>>>>>> 
>>>>>> My question today is about #1.  How to implement?  Karl
>>>>>> suggested stealing a bit from the type_datum->primary field to
>>>>>> indicate to the kernel that a certain type was a
> permissive domain.  Can I do this?
>>>>>> I guess this is a question for the setools group. Do you make
>>>>>> use of the actual value stored in 'primary'?  The kernel does
>>>>>> not.  Does anything make use of the actual value outside of the
>>>>>> tool chain? Please say 'no' and make this easier for me.
>>>>>> 
>>>>>> I want to throw away the 'primary' field all together in the
>>>>>> final binary policy and create a 'new' field called 'flags' in
>>>>>> its place. After my change flags would make use of 2 bits.
>>>>>> 
>>>>>> #define F_PRIMARY		0x00000001
>>>>>> #define F_PERMISSIVE		0x80000000
>>>>>> if (type_datum->old_primary)
>>>>>> 	type_datum->flags = F_PRIMARY; if (permissive domain)
>>>>>>     type_datum->flags |= F_PERMISSIVE
>>>>>> 
>>>>>> This only works if noone makes actual use of the value in
>>>>>> ->primary. If someone makes use of the value in primary I can't
>>>>>> really reuse that area on disk and I think I'm going to have to
>>>>>> bump the policy version and add a whole new ->flags field on
>>>>>> disk (I don't think pmoore's capability stuff really helps).
>  Maybe the
>>>>>> tools could just agree to ignore the last bit?  To be honest
>>>>>> I'm not personally terribly concerned about setools backwards
>>>>>> compatibility.  I'm really only thinking about function
>>>>>> backwards compatibility, so maybe the tools people would be ok
>>>>>> with me just userping a bit (but I'd much rather have a more
>>>>>> clear 'flags' than 'primary + one bit stolen for some other
>>>>>> random crap).  For backwards compatibility I might have to bump
>>>>>> the policy number even if noone has a problem with me
>>>>>> redefining the meaning of the ->primary field, not sure yet
>>>>>> haven't really wrapped my brain around it.  I think there is a
>>>>>> kernel bug which actually makes it possible to reuse the field
>>>>>> in my new way and maintain
>>>>> backwards kernel compatibility.
>>>>>> 
>>>>>> **The Bug**
>>>>>> In the binary policy on disk ->primary is a uint32_t but in the
>>>>>> kernel ->primary is an unsigned char.  When we load policy we
>>>>>> just have 
>>>>>> 
>>>>>> typdatum->primary = le32_to_cpu(buf[2]);
>>>>>> 
>>>>>> So we are truncating to 8 bits.  I think that means that if the
>>>>>> on disk ->primary value is greater than 0xFF but the lower 8
>>>>>> bits are all 0 we are going to screw this up (maybe this is
>>>>>> impossible, but I don't see why looking at libsepol quickly).
>>>>>> Thanks to this bug though I think I could use the 32nd bit of
>>>>>> the on disk representation on old kernels and they wouldn't even
>>>>>> realize it. New kernels could be made to pay attention to that
>>>>>> bit. Backwards compatibility through bugs, I love it. It also
>>>>>> means I don't really want to fix this bug right now *smile* **End
>>>>>> bug**
>>>>> 
>>>>> Kernel policy representation only uses ->primary as a boolean
>>>>> flag (is it a primary name or an alias, with the type index
>>>>> value in ->value regardless).  Modular policy introduced the
>>>>> notion of using it to store the primary type index for aliases
>>>>> (when ->flavor == TYPE_ALIAS).  By the time we reach kernel
>>>>> policy (after expansion), it should only be a boolean again.
>> 
>> I guess this being done in src/expand.c::type_copy_callback().
>> 
>> All my thought is for nothing though.  Somehow in the language we
>> have to represent permissive domains.  That in and of itself
>> requires a version bump doesn't it?  Drat.
>> 
>> So what format do we want to go with?
>> 
>> permissive httpd_t;
>> 
>> anyone got anything better?
>> 
>> So with the policy version bump should I add a new field, ->flags to
>> the on disk type_datum represenation?  Should I instead just rename
>> ->primary to ->flags and teach libsepol to mask off the flag?  I
>> don't know the toolchain well enough to know if we ever write more
>> than a boolean to disk in ->primary.  Guess that's what I'll look
>> for now but first glance tells me I might as well use another 32
>> bits on disk since it seems as though we have such disperate usage
>> of primary for POLICY_KERNEL vs everything else.
> 
> 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.

The last time we got rid of magic attributes with new contraints, maybe
we need an 'unconstrain' :)

> Only issue is that we loose attribute names in the kernel at
> present (expand strips them from the types symtab).  Which we
> should probably change - I'll concede it was a mistake to
> omit them when I started keeping attributes in rules in
> policy.20.  That would let the kernel then look up
> "permissive" and get the set of types that should be handled
> that way.  That's a format change though for the kernel, even
> if module format is unaffected.
> 

:)

> That would also have a side benefit for tools, as they could
> finally get attribute name info from kernel policy.  setools
> would like that, and audit2why could use it too (to identify
> what attribute would allow a constraint violation to pass).



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

RE: how to implement permissive domains + an old bug

[Stephen Smalley]

On Fri, 2008-02-15 at 15:17 -0500, Joshua Brindle wrote:
> Stephen Smalley wrote:
> > On Fri, 2008-02-15 at 14:43 -0500, Eric Paris wrote:
> >> On Fri, 2008-02-15 at 13:57 -0500, Stephen Smalley wrote:
> >>> On Fri, 2008-02-15 at 13:35 -0500, Joshua Brindle wrote:
> >>>> Stephen Smalley wrote:
> >>>>> On Fri, 2008-02-15 at 12:50 -0500, Eric Paris wrote:
> >>>>>> So after many months of trying to avoid it Dan finally beat me
> >>>>>> into looking at permissive domains.  I'm coming to the list to
> >>>>>> ask how people feel the transfer of knowledge that a domain is
> >>>>>> permissive between the policy and the kernel should be
> >>>>>> implemented.  (And to point out what I think is a bug I found
> >>>>>> while trolling around the code today)
> >>>>>> 
> >>>>>> Old discussion of permissive domains.
> >>>>>> http://marc.info/?l=selinux&m=118953810913436&w=2
> >>>>>> 
> >>>>>> The basic idea is that we want a domain in which a process can
> >>>>>> run without any permission enforcement and without flooding the
> >>>>>> audit logs. After much discussion I think everyone agreed with
> >>>>>> (or at least stopped arguing against) a couple of things.
> >>>>>> 
> >>>>>> 1) do this in policy (not selinuxfs)
> >>>>>> 2) have it act just like 'setenforce 0'
> >>>>>> 
> >>>>>> My question today is about #1.  How to implement?  Karl
> >>>>>> suggested stealing a bit from the type_datum->primary field to
> >>>>>> indicate to the kernel that a certain type was a
> > permissive domain.  Can I do this?
> >>>>>> I guess this is a question for the setools group. Do you make
> >>>>>> use of the actual value stored in 'primary'?  The kernel does
> >>>>>> not.  Does anything make use of the actual value outside of the
> >>>>>> tool chain? Please say 'no' and make this easier for me.
> >>>>>> 
> >>>>>> I want to throw away the 'primary' field all together in the
> >>>>>> final binary policy and create a 'new' field called 'flags' in
> >>>>>> its place. After my change flags would make use of 2 bits.
> >>>>>> 
> >>>>>> #define F_PRIMARY		0x00000001
> >>>>>> #define F_PERMISSIVE		0x80000000
> >>>>>> if (type_datum->old_primary)
> >>>>>> 	type_datum->flags = F_PRIMARY; if (permissive domain)
> >>>>>>     type_datum->flags |= F_PERMISSIVE
> >>>>>> 
> >>>>>> This only works if noone makes actual use of the value in
> >>>>>> ->primary. If someone makes use of the value in primary I can't
> >>>>>> really reuse that area on disk and I think I'm going to have to
> >>>>>> bump the policy version and add a whole new ->flags field on
> >>>>>> disk (I don't think pmoore's capability stuff really helps).
> >  Maybe the
> >>>>>> tools could just agree to ignore the last bit?  To be honest
> >>>>>> I'm not personally terribly concerned about setools backwards
> >>>>>> compatibility.  I'm really only thinking about function
> >>>>>> backwards compatibility, so maybe the tools people would be ok
> >>>>>> with me just userping a bit (but I'd much rather have a more
> >>>>>> clear 'flags' than 'primary + one bit stolen for some other
> >>>>>> random crap).  For backwards compatibility I might have to bump
> >>>>>> the policy number even if noone has a problem with me
> >>>>>> redefining the meaning of the ->primary field, not sure yet
> >>>>>> haven't really wrapped my brain around it.  I think there is a
> >>>>>> kernel bug which actually makes it possible to reuse the field
> >>>>>> in my new way and maintain
> >>>>> backwards kernel compatibility.
> >>>>>> 
> >>>>>> **The Bug**
> >>>>>> In the binary policy on disk ->primary is a uint32_t but in the
> >>>>>> kernel ->primary is an unsigned char.  When we load policy we
> >>>>>> just have 
> >>>>>> 
> >>>>>> typdatum->primary = le32_to_cpu(buf[2]);
> >>>>>> 
> >>>>>> So we are truncating to 8 bits.  I think that means that if the
> >>>>>> on disk ->primary value is greater than 0xFF but the lower 8
> >>>>>> bits are all 0 we are going to screw this up (maybe this is
> >>>>>> impossible, but I don't see why looking at libsepol quickly).
> >>>>>> Thanks to this bug though I think I could use the 32nd bit of
> >>>>>> the on disk representation on old kernels and they wouldn't even
> >>>>>> realize it. New kernels could be made to pay attention to that
> >>>>>> bit. Backwards compatibility through bugs, I love it. It also
> >>>>>> means I don't really want to fix this bug right now *smile* **End
> >>>>>> bug**
> >>>>> 
> >>>>> Kernel policy representation only uses ->primary as a boolean
> >>>>> flag (is it a primary name or an alias, with the type index
> >>>>> value in ->value regardless).  Modular policy introduced the
> >>>>> notion of using it to store the primary type index for aliases
> >>>>> (when ->flavor == TYPE_ALIAS).  By the time we reach kernel
> >>>>> policy (after expansion), it should only be a boolean again.
> >> 
> >> I guess this being done in src/expand.c::type_copy_callback().
> >> 
> >> All my thought is for nothing though.  Somehow in the language we
> >> have to represent permissive domains.  That in and of itself
> >> requires a version bump doesn't it?  Drat.
> >> 
> >> So what format do we want to go with?
> >> 
> >> permissive httpd_t;
> >> 
> >> anyone got anything better?
> >> 
> >> So with the policy version bump should I add a new field, ->flags to
> >> the on disk type_datum represenation?  Should I instead just rename
> >> ->primary to ->flags and teach libsepol to mask off the flag?  I
> >> don't know the toolchain well enough to know if we ever write more
> >> than a boolean to disk in ->primary.  Guess that's what I'll look
> >> for now but first glance tells me I might as well use another 32
> >> bits on disk since it seems as though we have such disperate usage
> >> of primary for POLICY_KERNEL vs everything else.
> > 
> > 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.

> The last time we got rid of magic attributes with new contraints, maybe
> we need an 'unconstrain' :)

-- 
Stephen Smalley
National Security Agency


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

Re: how to implement permissive domains + an old bug

[Daniel J Walsh]

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

Stephen Smalley wrote:
> On Fri, 2008-02-15 at 15:17 -0500, Joshua Brindle wrote:
>> Stephen Smalley wrote:
>>> On Fri, 2008-02-15 at 14:43 -0500, Eric Paris wrote:
>>>> On Fri, 2008-02-15 at 13:57 -0500, Stephen Smalley wrote:
>>>>> On Fri, 2008-02-15 at 13:35 -0500, Joshua Brindle wrote:
>>>>>> Stephen Smalley wrote:
>>>>>>> On Fri, 2008-02-15 at 12:50 -0500, Eric Paris wrote:
>>>>>>>> So after many months of trying to avoid it Dan finally beat me
>>>>>>>> into looking at permissive domains.  I'm coming to the list to
>>>>>>>> ask how people feel the transfer of knowledge that a domain is
>>>>>>>> permissive between the policy and the kernel should be
>>>>>>>> implemented.  (And to point out what I think is a bug I found
>>>>>>>> while trolling around the code today)
>>>>>>>>
>>>>>>>> Old discussion of permissive domains.
>>>>>>>> http://marc.info/?l=selinux&m=118953810913436&w=2
>>>>>>>>
>>>>>>>> The basic idea is that we want a domain in which a process can
>>>>>>>> run without any permission enforcement and without flooding the
>>>>>>>> audit logs. After much discussion I think everyone agreed with
>>>>>>>> (or at least stopped arguing against) a couple of things.
>>>>>>>>
>>>>>>>> 1) do this in policy (not selinuxfs)
>>>>>>>> 2) have it act just like 'setenforce 0'
>>>>>>>>
>>>>>>>> My question today is about #1.  How to implement?  Karl
>>>>>>>> suggested stealing a bit from the type_datum->primary field to
>>>>>>>> indicate to the kernel that a certain type was a
>>> permissive domain.  Can I do this?
>>>>>>>> I guess this is a question for the setools group. Do you make
>>>>>>>> use of the actual value stored in 'primary'?  The kernel does
>>>>>>>> not.  Does anything make use of the actual value outside of the
>>>>>>>> tool chain? Please say 'no' and make this easier for me.
>>>>>>>>
>>>>>>>> I want to throw away the 'primary' field all together in the
>>>>>>>> final binary policy and create a 'new' field called 'flags' in
>>>>>>>> its place. After my change flags would make use of 2 bits.
>>>>>>>>
>>>>>>>> #define F_PRIMARY		0x00000001
>>>>>>>> #define F_PERMISSIVE		0x80000000
>>>>>>>> if (type_datum->old_primary)
>>>>>>>> 	type_datum->flags = F_PRIMARY; if (permissive domain)
>>>>>>>>     type_datum->flags |= F_PERMISSIVE
>>>>>>>>
>>>>>>>> This only works if noone makes actual use of the value in
>>>>>>>> ->primary. If someone makes use of the value in primary I can't
>>>>>>>> really reuse that area on disk and I think I'm going to have to
>>>>>>>> bump the policy version and add a whole new ->flags field on
>>>>>>>> disk (I don't think pmoore's capability stuff really helps).
>>>  Maybe the
>>>>>>>> tools could just agree to ignore the last bit?  To be honest
>>>>>>>> I'm not personally terribly concerned about setools backwards
>>>>>>>> compatibility.  I'm really only thinking about function
>>>>>>>> backwards compatibility, so maybe the tools people would be ok
>>>>>>>> with me just userping a bit (but I'd much rather have a more
>>>>>>>> clear 'flags' than 'primary + one bit stolen for some other
>>>>>>>> random crap).  For backwards compatibility I might have to bump
>>>>>>>> the policy number even if noone has a problem with me
>>>>>>>> redefining the meaning of the ->primary field, not sure yet
>>>>>>>> haven't really wrapped my brain around it.  I think there is a
>>>>>>>> kernel bug which actually makes it possible to reuse the field
>>>>>>>> in my new way and maintain
>>>>>>> backwards kernel compatibility.
>>>>>>>> **The Bug**
>>>>>>>> In the binary policy on disk ->primary is a uint32_t but in the
>>>>>>>> kernel ->primary is an unsigned char.  When we load policy we
>>>>>>>> just have 
>>>>>>>>
>>>>>>>> typdatum->primary = le32_to_cpu(buf[2]);
>>>>>>>>
>>>>>>>> So we are truncating to 8 bits.  I think that means that if the
>>>>>>>> on disk ->primary value is greater than 0xFF but the lower 8
>>>>>>>> bits are all 0 we are going to screw this up (maybe this is
>>>>>>>> impossible, but I don't see why looking at libsepol quickly).
>>>>>>>> Thanks to this bug though I think I could use the 32nd bit of
>>>>>>>> the on disk representation on old kernels and they wouldn't even
>>>>>>>> realize it. New kernels could be made to pay attention to that
>>>>>>>> bit. Backwards compatibility through bugs, I love it. It also
>>>>>>>> means I don't really want to fix this bug right now *smile* **End
>>>>>>>> bug**
>>>>>>> Kernel policy representation only uses ->primary as a boolean
>>>>>>> flag (is it a primary name or an alias, with the type index
>>>>>>> value in ->value regardless).  Modular policy introduced the
>>>>>>> notion of using it to store the primary type index for aliases
>>>>>>> (when ->flavor == TYPE_ALIAS).  By the time we reach kernel
>>>>>>> policy (after expansion), it should only be a boolean again.
>>>> I guess this being done in src/expand.c::type_copy_callback().
>>>>
>>>> All my thought is for nothing though.  Somehow in the language we
>>>> have to represent permissive domains.  That in and of itself
>>>> requires a version bump doesn't it?  Drat.
>>>>
>>>> So what format do we want to go with?
>>>>
>>>> permissive httpd_t;
>>>>
>>>> anyone got anything better?
>>>>
>>>> So with the policy version bump should I add a new field, ->flags to
>>>> the on disk type_datum represenation?  Should I instead just rename
>>>> ->primary to ->flags and teach libsepol to mask off the flag?  I
>>>> don't know the toolchain well enough to know if we ever write more
>>>> than a boolean to disk in ->primary.  Guess that's what I'll look
>>>> for now but first glance tells me I might as well use another 32
>>>> bits on disk since it seems as though we have such disperate usage
>>>> of primary for POLICY_KERNEL vs everything else.
>>> 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.
> 
>> 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.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkfCyiUACgkQrlYvE4MpobMNHwCdF58IIyNosjVn1Xu3ppUzGUY+
BFsAn03dcKt62KONJCadKluGLEJyOnV3
=mj+K
-----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.

RE: how to implement permissive domains + an old bug

[Joshua Brindle]

Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Stephen Smalley wrote:
>> On Fri, 2008-02-15 at 15:17 -0500, Joshua Brindle wrote:
>>> Stephen Smalley wrote:
>>>> On Fri, 2008-02-15 at 14:43 -0500, Eric Paris wrote:
>>>>> On Fri, 2008-02-15 at 13:57 -0500, Stephen Smalley wrote:
>>>>>> On Fri, 2008-02-15 at 13:35 -0500, Joshua Brindle wrote:
>>>>>>> Stephen Smalley wrote:
>>>>>>>> On Fri, 2008-02-15 at 12:50 -0500, Eric Paris wrote:
>>>>>>>>> So after many months of trying to avoid it Dan finally beat me
>>>>>>>>> into looking at permissive domains.  I'm coming to the list to
>>>>>>>>> ask how people feel the transfer of knowledge that a domain is
>>>>>>>>> permissive between the policy and the kernel should be
>>>>>>>>> implemented.  (And to point out what I think is a bug I found
>>>>>>>>> while trolling around the code today)
>>>>>>>>> 
>>>>>>>>> Old discussion of permissive domains.
>>>>>>>>> http://marc.info/?l=selinux&m=118953810913436&w=2
>>>>>>>>> 
>>>>>>>>> The basic idea is that we want a domain in which a process can
>>>>>>>>> run without any permission enforcement and without flooding
>>>>>>>>> the audit logs. After much discussion I think everyone agreed
>>>>>>>>> with (or at least stopped arguing against) a couple of things.
>>>>>>>>> 
>>>>>>>>> 1) do this in policy (not selinuxfs)
>>>>>>>>> 2) have it act just like 'setenforce 0'
>>>>>>>>> 
>>>>>>>>> My question today is about #1.  How to implement?  Karl
>>>>>>>>> suggested stealing a bit from the type_datum->primary field to
>>>>>>>>> indicate to the kernel that a certain type was a
>>>> permissive domain.  Can I do this?
>>>>>>>>> I guess this is a question for the setools group. Do you make
>>>>>>>>> use of the actual value stored in 'primary'?  The kernel does
>>>>>>>>> not.  Does anything make use of the actual value outside of
>>>>>>>>> the tool chain? Please say 'no' and make this easier for me.
>>>>>>>>> 
>>>>>>>>> I want to throw away the 'primary' field all together in the
>>>>>>>>> final binary policy and create a 'new' field called 'flags' in
>>>>>>>>> its place. After my change flags would make use of 2 bits.
>>>>>>>>> 
>>>>>>>>> #define F_PRIMARY		0x00000001
>>>>>>>>> #define F_PERMISSIVE		0x80000000
>>>>>>>>> if (type_datum->old_primary)
>>>>>>>>> 	type_datum->flags = F_PRIMARY; if (permissive domain)
>>>>>>>>>     type_datum->flags |= F_PERMISSIVE
>>>>>>>>> 
>>>>>>>>> This only works if noone makes actual use of the value in
>>>>>>>>> ->primary. If someone makes use of the value in primary I
>>>>>>>>> can't really reuse that area on disk and I think I'm going to
>>>>>>>>> have to bump the policy version and add a whole new ->flags
>>>>>>>>> field on disk (I don't think pmoore's capability stuff really
>>>>>>>>> helps). 
>>>>  Maybe the
>>>>>>>>> tools could just agree to ignore the last bit?  To be honest
>>>>>>>>> I'm not personally terribly concerned about setools backwards
>>>>>>>>> compatibility.  I'm really only thinking about function
>>>>>>>>> backwards compatibility, so maybe the tools people would be ok
>>>>>>>>> with me just userping a bit (but I'd much rather have a more
>>>>>>>>> clear 'flags' than 'primary + one bit stolen for some other
>>>>>>>>> random crap).  For backwards compatibility I might have to
>>>>>>>>> bump the policy number even if noone has a problem with me
>>>>>>>>> redefining the meaning of the ->primary field, not sure yet
>>>>>>>>> haven't really wrapped my brain around it.  I think there is a
>>>>>>>>> kernel bug which actually makes it possible to reuse the field
>>>>>>>>> in my new way and maintain
>>>>>>>> backwards kernel compatibility.
>>>>>>>>> **The Bug**
>>>>>>>>> In the binary policy on disk ->primary is a uint32_t but in
>>>>>>>>> the kernel ->primary is an unsigned char.  When we load
>>>>>>>>> policy we just have 
>>>>>>>>> 
>>>>>>>>> typdatum->primary = le32_to_cpu(buf[2]);
>>>>>>>>> 
>>>>>>>>> So we are truncating to 8 bits.  I think that means that if
>>>>>>>>> the on disk ->primary value is greater than 0xFF but the
>>>>>>>>> lower 8 bits are all 0 we are going to screw this up (maybe
>>>>>>>>> this is impossible, but I don't see why looking at libsepol
>>>>>>>>> quickly). Thanks to this bug though I think I could use the
>>>>>>>>> 32nd bit of the on disk representation on old kernels and
>>>>>>>>> they wouldn't even realize it. New kernels could be made to
>>>>>>>>> pay attention to that bit. Backwards compatibility through
>>>>>>>>> bugs, I love it. It also means I don't really want to fix
>>>>>>>>> this bug right now *smile* **End bug**
>>>>>>>> Kernel policy representation only uses ->primary as a boolean
>>>>>>>> flag (is it a primary name or an alias, with the type index
>>>>>>>> value in ->value regardless).  Modular policy introduced the
>>>>>>>> notion of using it to store the primary type index for aliases
>>>>>>>> (when ->flavor == TYPE_ALIAS).  By the time we reach kernel
>>>>>>>> policy (after expansion), it should only be a boolean again.
>>>>> I guess this being done in src/expand.c::type_copy_callback().
>>>>> 
>>>>> All my thought is for nothing though.  Somehow in the language we
>>>>> have to represent permissive domains.  That in and of itself
>>>>> requires a version bump doesn't it?  Drat.
>>>>> 
>>>>> So what format do we want to go with?
>>>>> 
>>>>> permissive httpd_t;
>>>>> 
>>>>> anyone got anything better?
>>>>> 
>>>>> So with the policy version bump should I add a new field, ->flags
>>>>> to the on disk type_datum represenation?  Should I instead just
>>>>> rename ->primary to ->flags and teach libsepol to mask off the
>>>>> flag?  I don't know the toolchain well enough to know if we ever
>>>>> write more than a boolean to disk in ->primary.  Guess that's
>>>>> what I'll look for now but first glance tells me I might as well
>>>>> use another 32 bits on disk since it seems as though we have such
>>>>> disperate usage of primary for POLICY_KERNEL vs everything else.
>>>> 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.


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

RE: how to implement permissive domains + an old bug

[Stephen Smalley]

On Mon, 2008-02-25 at 09:53 -0500, Joshua Brindle wrote:
> Daniel J Walsh wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Stephen Smalley wrote:
> >> On Fri, 2008-02-15 at 15:17 -0500, Joshua Brindle wrote:
> >>> Stephen Smalley wrote:
> >>>> On Fri, 2008-02-15 at 14:43 -0500, Eric Paris wrote:
> >>>>> On Fri, 2008-02-15 at 13:57 -0500, Stephen Smalley wrote:
> >>>>>> On Fri, 2008-02-15 at 13:35 -0500, Joshua Brindle wrote:
> >>>>>>> Stephen Smalley wrote:
> >>>>>>>> On Fri, 2008-02-15 at 12:50 -0500, Eric Paris wrote:
> >>>>>>>>> So after many months of trying to avoid it Dan finally beat me
> >>>>>>>>> into looking at permissive domains.  I'm coming to the list to
> >>>>>>>>> ask how people feel the transfer of knowledge that a domain is
> >>>>>>>>> permissive between the policy and the kernel should be
> >>>>>>>>> implemented.  (And to point out what I think is a bug I found
> >>>>>>>>> while trolling around the code today)
> >>>>>>>>> 
> >>>>>>>>> Old discussion of permissive domains.
> >>>>>>>>> http://marc.info/?l=selinux&m=118953810913436&w=2
> >>>>>>>>> 
> >>>>>>>>> The basic idea is that we want a domain in which a process can
> >>>>>>>>> run without any permission enforcement and without flooding
> >>>>>>>>> the audit logs. After much discussion I think everyone agreed
> >>>>>>>>> with (or at least stopped arguing against) a couple of things.
> >>>>>>>>> 
> >>>>>>>>> 1) do this in policy (not selinuxfs)
> >>>>>>>>> 2) have it act just like 'setenforce 0'
> >>>>>>>>> 
> >>>>>>>>> My question today is about #1.  How to implement?  Karl
> >>>>>>>>> suggested stealing a bit from the type_datum->primary field to
> >>>>>>>>> indicate to the kernel that a certain type was a
> >>>> permissive domain.  Can I do this?
> >>>>>>>>> I guess this is a question for the setools group. Do you make
> >>>>>>>>> use of the actual value stored in 'primary'?  The kernel does
> >>>>>>>>> not.  Does anything make use of the actual value outside of
> >>>>>>>>> the tool chain? Please say 'no' and make this easier for me.
> >>>>>>>>> 
> >>>>>>>>> I want to throw away the 'primary' field all together in the
> >>>>>>>>> final binary policy and create a 'new' field called 'flags' in
> >>>>>>>>> its place. After my change flags would make use of 2 bits.
> >>>>>>>>> 
> >>>>>>>>> #define F_PRIMARY		0x00000001
> >>>>>>>>> #define F_PERMISSIVE		0x80000000
> >>>>>>>>> if (type_datum->old_primary)
> >>>>>>>>> 	type_datum->flags = F_PRIMARY; if (permissive domain)
> >>>>>>>>>     type_datum->flags |= F_PERMISSIVE
> >>>>>>>>> 
> >>>>>>>>> This only works if noone makes actual use of the value in
> >>>>>>>>> ->primary. If someone makes use of the value in primary I
> >>>>>>>>> can't really reuse that area on disk and I think I'm going to
> >>>>>>>>> have to bump the policy version and add a whole new ->flags
> >>>>>>>>> field on disk (I don't think pmoore's capability stuff really
> >>>>>>>>> helps). 
> >>>>  Maybe the
> >>>>>>>>> tools could just agree to ignore the last bit?  To be honest
> >>>>>>>>> I'm not personally terribly concerned about setools backwards
> >>>>>>>>> compatibility.  I'm really only thinking about function
> >>>>>>>>> backwards compatibility, so maybe the tools people would be ok
> >>>>>>>>> with me just userping a bit (but I'd much rather have a more
> >>>>>>>>> clear 'flags' than 'primary + one bit stolen for some other
> >>>>>>>>> random crap).  For backwards compatibility I might have to
> >>>>>>>>> bump the policy number even if noone has a problem with me
> >>>>>>>>> redefining the meaning of the ->primary field, not sure yet
> >>>>>>>>> haven't really wrapped my brain around it.  I think there is a
> >>>>>>>>> kernel bug which actually makes it possible to reuse the field
> >>>>>>>>> in my new way and maintain
> >>>>>>>> backwards kernel compatibility.
> >>>>>>>>> **The Bug**
> >>>>>>>>> In the binary policy on disk ->primary is a uint32_t but in
> >>>>>>>>> the kernel ->primary is an unsigned char.  When we load
> >>>>>>>>> policy we just have 
> >>>>>>>>> 
> >>>>>>>>> typdatum->primary = le32_to_cpu(buf[2]);
> >>>>>>>>> 
> >>>>>>>>> So we are truncating to 8 bits.  I think that means that if
> >>>>>>>>> the on disk ->primary value is greater than 0xFF but the
> >>>>>>>>> lower 8 bits are all 0 we are going to screw this up (maybe
> >>>>>>>>> this is impossible, but I don't see why looking at libsepol
> >>>>>>>>> quickly). Thanks to this bug though I think I could use the
> >>>>>>>>> 32nd bit of the on disk representation on old kernels and
> >>>>>>>>> they wouldn't even realize it. New kernels could be made to
> >>>>>>>>> pay attention to that bit. Backwards compatibility through
> >>>>>>>>> bugs, I love it. It also means I don't really want to fix
> >>>>>>>>> this bug right now *smile* **End bug**
> >>>>>>>> Kernel policy representation only uses ->primary as a boolean
> >>>>>>>> flag (is it a primary name or an alias, with the type index
> >>>>>>>> value in ->value regardless).  Modular policy introduced the
> >>>>>>>> notion of using it to store the primary type index for aliases
> >>>>>>>> (when ->flavor == TYPE_ALIAS).  By the time we reach kernel
> >>>>>>>> policy (after expansion), it should only be a boolean again.
> >>>>> I guess this being done in src/expand.c::type_copy_callback().
> >>>>> 
> >>>>> All my thought is for nothing though.  Somehow in the language we
> >>>>> have to represent permissive domains.  That in and of itself
> >>>>> requires a version bump doesn't it?  Drat.
> >>>>> 
> >>>>> So what format do we want to go with?
> >>>>> 
> >>>>> permissive httpd_t;
> >>>>> 
> >>>>> anyone got anything better?
> >>>>> 
> >>>>> So with the policy version bump should I add a new field, ->flags
> >>>>> to the on disk type_datum represenation?  Should I instead just
> >>>>> rename ->primary to ->flags and teach libsepol to mask off the
> >>>>> flag?  I don't know the toolchain well enough to know if we ever
> >>>>> write more than a boolean to disk in ->primary.  Guess that's
> >>>>> what I'll look for now but first glance tells me I might as well
> >>>>> use another 32 bits on disk since it seems as though we have such
> >>>>> disperate usage of primary for POLICY_KERNEL vs everything else.
> >>>> 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.

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.

Maybe it would help if Eric could post or point to prior posting if one
exists of his earlier experimental patch (offhand, I couldn't dig it up
quickly).

-- 
Stephen Smalley
National Security Agency


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

RE: how to implement permissive domains + an old bug

[Eric Paris]

On Mon, 2008-02-25 at 14:48 -0500, Stephen Smalley wrote:
> On Mon, 2008-02-25 at 09:53 -0500, Joshua Brindle wrote:
> > Daniel J Walsh wrote:

> Maybe it would help if Eric could post or point to prior posting if one
> exists of his earlier experimental patch (offhand, I couldn't dig it up
> quickly).

THIS PATCH DOESN'T APPLY AND DOESN'T WORK.  I just dug it out of an
ancient git tree and haven't looked at it since Sept 17th (at least that
was my last commit on this branch).  It still has 'special' usage of
auditdeny which I don't plan to include when we get back to this.

Wow Dan, I really can ignore you for a long time...

-Eric

diff --git a/security/selinux/avc.c b/security/selinux/avc.c
index 0e69adf..91b9ec6 100644
--- a/security/selinux/avc.c
+++ b/security/selinux/avc.c
@@ -877,7 +877,17 @@ int avc_has_perm_noaudit(u32 ssid, u32 tsid,
 	denied = requested & ~(p_ae->avd.allowed);
 
 	if (!requested || denied) {
-		if (selinux_enforcing || (flags & AVC_STRICT))
+		if (selinux_enforcing)
+			if ((unlikely(security_permissive_sid(ssid)) > 0) &&
+			    requested &&
+			    !(requested & avd->auditdeny)) {
+				if (node)
+					avc_update_node(AVC_CALLBACK_GRANT,requested,
+							ssid,tsid,tclass);
+			}
+			else
+				rc = -EACCES;
+		else if (flags & AVC_STRICT)
 			rc = -EACCES;
 		else
 			if (node)
diff --git a/security/selinux/include/security.h b/security/selinux/include/security.h
index 83bdd4d..3832899 100644
--- a/security/selinux/include/security.h
+++ b/security/selinux/include/security.h
@@ -50,6 +50,8 @@ struct av_decision {
 	u32 seqno;
 };
 
+int security_permissive_sid(u32 sid);
+
 int security_compute_av(u32 ssid, u32 tsid,
 	u16 tclass, u32 requested,
 	struct av_decision *avd);
diff --git a/security/selinux/ss/policydb.c b/security/selinux/ss/policydb.c
index f05f97a..205006d 100644
--- a/security/selinux/ss/policydb.c
+++ b/security/selinux/ss/policydb.c
@@ -254,7 +254,7 @@ static int type_index(void *key, void *datum, void *datap)
 	typdatum = datum;
 	p = datap;
 
-	if (typdatum->primary) {
+	if (typdatum->flags & PRIMARY_MASK) {
 		if (!typdatum->value || typdatum->value > p->p_types.nprim)
 			return -EINVAL;
 		p->p_type_val_to_name[typdatum->value - 1] = key;
@@ -1215,7 +1215,7 @@ static int type_read(struct policydb *p, struct hashtab *h, void *fp)
 
 	len = le32_to_cpu(buf[0]);
 	typdatum->value = le32_to_cpu(buf[1]);
-	typdatum->primary = le32_to_cpu(buf[2]);
+	typdatum->flags = le32_to_cpu(buf[2]);
 
 	key = kmalloc(len + 1,GFP_KERNEL);
 	if (!key) {
diff --git a/security/selinux/ss/policydb.h b/security/selinux/ss/policydb.h
index 8319d5f..c0bd006 100644
--- a/security/selinux/ss/policydb.h
+++ b/security/selinux/ss/policydb.h
@@ -81,7 +81,9 @@ struct role_allow {
 /* Type attributes */
 struct type_datum {
 	u32 value;		/* internal type value */
-	unsigned char primary;	/* primary name? */
+	unsigned char flags;	/* primary name? */
+#define PRIMARY_MASK 0x01
+#define PERMISSIVE_MASK 0x02
 };
 
 /* User attributes */
diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
index f00161e..343dd70 100644
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -389,6 +389,23 @@ static int context_struct_compute_av(struct context *scontext,
 	return 0;
 }
 
+int security_permissive_sid(u32 sid)
+{
+	struct type_datum *typdatum;
+	char *context;
+	int rc;
+	u32 len;
+	rc = security_sid_to_context(sid, &context, &len);
+	if (rc)
+		return rc;
+
+	typdatum = hashtab_search(policydb.p_types.table, context);
+	if (!typdatum)
+		return 0;
+
+	return (typdatum->flags && PERMISSIVE_MASK);
+}
+
 static int security_validtrans_handle_fail(struct context *ocontext,
                                            struct context *ncontext,
                                            struct context *tcontext,



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

RE: how to implement permissive domains + an old bug

[Joshua Brindle]

Stephen Smalley wrote:
> On Mon, 2008-02-25 at 09:53 -0500, Joshua Brindle wrote:
>> Daniel J Walsh wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>> 
>>> Stephen Smalley wrote:
>>>> On Fri, 2008-02-15 at 15:17 -0500, Joshua Brindle wrote:
>>>>> Stephen Smalley wrote:
>>>>>> On Fri, 2008-02-15 at 14:43 -0500, Eric Paris wrote:
>>>>>>> On Fri, 2008-02-15 at 13:57 -0500, Stephen Smalley wrote:
>>>>>>>> On Fri, 2008-02-15 at 13:35 -0500, Joshua Brindle wrote:
>>>>>>>>> Stephen Smalley wrote:
>>>>>>>>>> On Fri, 2008-02-15 at 12:50 -0500, Eric Paris wrote:
>>>>>>>>>>> So after many months of trying to avoid it Dan finally beat
>>>>>>>>>>> me into looking at permissive domains.  I'm coming to the
>>>>>>>>>>> list to ask how people feel the transfer of knowledge that a
>>>>>>>>>>> domain is permissive between the policy and the kernel
>>>>>>>>>>> should be implemented.  (And to point out what I think is a
>>>>>>>>>>> bug I found while trolling around the code today)
>>>>>>>>>>> 
>>>>>>>>>>> Old discussion of permissive domains.
>>>>>>>>>>> http://marc.info/?l=selinux&m=118953810913436&w=2
>>>>>>>>>>> 
>>>>>>>>>>> The basic idea is that we want a domain in which a process
>>>>>>>>>>> can run without any permission enforcement and without
>>>>>>>>>>> flooding the audit logs. After much discussion I think
>>>>>>>>>>> everyone agreed with (or at least stopped arguing against)
>>>>>>>>>>> a couple of things. 
>>>>>>>>>>> 
>>>>>>>>>>> 1) do this in policy (not selinuxfs)
>>>>>>>>>>> 2) have it act just like 'setenforce 0'
>>>>>>>>>>> 
>>>>>>>>>>> My question today is about #1.  How to implement?  Karl
>>>>>>>>>>> suggested stealing a bit from the type_datum->primary field
>>>>>>>>>>> to indicate to the kernel that a certain type was a
>>>>>> permissive domain.  Can I do this?
>>>>>>>>>>> I guess this is a question for the setools group. Do you
>>>>>>>>>>> make use of the actual value stored in 'primary'?  The
>>>>>>>>>>> kernel does not.  Does anything make use of the actual value
>>>>>>>>>>> outside of the tool chain? Please say 'no' and make this
>>>>>>>>>>> easier for me. 
>>>>>>>>>>> 
>>>>>>>>>>> I want to throw away the 'primary' field all together in the
>>>>>>>>>>> final binary policy and create a 'new' field called 'flags'
>>>>>>>>>>> in its place. After my change flags would make use of 2
>>>>>>>>>>> bits. 
>>>>>>>>>>> 
>>>>>>>>>>> #define F_PRIMARY		0x00000001
>>>>>>>>>>> #define F_PERMISSIVE		0x80000000
>>>>>>>>>>> if (type_datum->old_primary)
>>>>>>>>>>> 	type_datum->flags = F_PRIMARY; if (permissive domain)
>>>>>>>>>>>     type_datum->flags |= F_PERMISSIVE
>>>>>>>>>>> 
>>>>>>>>>>> This only works if noone makes actual use of the value in
>>>>>>>>>>> ->primary. If someone makes use of the value in primary I
>>>>>>>>>>> can't really reuse that area on disk and I think I'm going
>>>>>>>>>>> to have to bump the policy version and add a whole new
>>>>>>>>>>> ->flags field on disk (I don't think pmoore's capability
>>>>>>>>>>> stuff really helps).
>>>>>>  Maybe the
>>>>>>>>>>> tools could just agree to ignore the last bit? To be honest
>>>>>>>>>>> I'm not personally terribly concerned about setools
>>>>>>>>>>> backwards compatibility.  I'm really only thinking about
>>>>>>>>>>> function backwards compatibility, so maybe the tools people
>>>>>>>>>>> would be ok with me just userping a bit (but I'd much rather
>>>>>>>>>>> have a more clear 'flags' than 'primary + one bit stolen for
>>>>>>>>>>> some other random crap).  For backwards compatibility I
>>>>>>>>>>> might have to bump the policy number even if noone has a
>>>>>>>>>>> problem with me redefining the meaning of the ->primary
>>>>>>>>>>> field, not sure yet haven't really wrapped my brain around
>>>>>>>>>>> it.  I think there is a kernel bug which actually makes it
>>>>>>>>>>> possible to reuse the field in my new way and maintain
>>>>>>>>>> backwards kernel compatibility.
>>>>>>>>>>> **The Bug**
>>>>>>>>>>> In the binary policy on disk ->primary is a uint32_t but in
>>>>>>>>>>> the kernel ->primary is an unsigned char.  When we load
>>>>>>>>>>> policy we just have 
>>>>>>>>>>> 
>>>>>>>>>>> typdatum->primary = le32_to_cpu(buf[2]);
>>>>>>>>>>> 
>>>>>>>>>>> So we are truncating to 8 bits.  I think that means that if
>>>>>>>>>>> the on disk ->primary value is greater than 0xFF but the
>>>>>>>>>>> lower 8 bits are all 0 we are going to screw this up (maybe
>>>>>>>>>>> this is impossible, but I don't see why looking at libsepol
>>>>>>>>>>> quickly). Thanks to this bug though I think I could use the
>>>>>>>>>>> 32nd bit of the on disk representation on old kernels and
>>>>>>>>>>> they wouldn't even realize it. New kernels could be made to
>>>>>>>>>>> pay attention to that bit. Backwards compatibility through
>>>>>>>>>>> bugs, I love it. It also means I don't really want to fix
>>>>>>>>>>> this bug right now *smile* **End bug**
>>>>>>>>>> Kernel policy representation only uses ->primary as a boolean
>>>>>>>>>> flag (is it a primary name or an alias, with the type index
>>>>>>>>>> value in ->value regardless).  Modular policy introduced the
>>>>>>>>>> notion of using it to store the primary type index for
>>>>>>>>>> aliases (when ->flavor == TYPE_ALIAS).  By the time we reach
>>>>>>>>>> kernel policy (after expansion), it should only be
> a boolean again.
>>>>>>> I guess this being done in src/expand.c::type_copy_callback().
>>>>>>> 
>>>>>>> All my thought is for nothing though.  Somehow in the language
>>>>>>> we have to represent permissive domains.  That in and of itself
>>>>>>> requires a version bump doesn't it?  Drat.
>>>>>>> 
>>>>>>> So what format do we want to go with?
>>>>>>> 
>>>>>>> permissive httpd_t;
>>>>>>> 
>>>>>>> anyone got anything better?
>>>>>>> 
>>>>>>> So with the policy version bump should I add a new field,
>>>>>>> ->flags to the on disk type_datum represenation?  Should I
>>>>>>> instead just rename ->primary to ->flags and teach libsepol to
>>>>>>> mask off the flag?  I don't know the toolchain well enough to
>>>>>>> know if we ever write more than a boolean to disk in ->primary.
>>>>>>> Guess that's what I'll look for now but first glance tells me I
>>>>>>> might as well use another 32 bits on disk since it seems as
>>>>>>> though we have such disperate usage of primary for
> POLICY_KERNEL vs everything else.
>>>>>> 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?


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

RE: how to implement permissive domains + an old bug

[Christopher J. PeBenito]

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.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


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

Re: how to implement permissive domains + an old bug

[Daniel J Walsh]

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

RE: how to implement permissive domains + an old bug

[Todd Miller]

Christopher J. PeBenito wrote:
> 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.

To my mind the important thing to decide is whether permissive domains
should be persistent in the policy or not.  If not, then an entry in
selinuxfs would be appropriate.  If we do want it to be persistent,
our options include making it a policy primitive, a magic type
attribute, or an semanage option.  Of those, only the policy primitive
requires changes to the policy parser.

I don't have a strong opinion on this myself, though my gut reaction is
that persistence is a useful property.

 - todd


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

Re: how to implement permissive domains + an old bug

[Daniel J Walsh]

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

Todd Miller wrote:
> Christopher J. PeBenito wrote:
>> 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.
> 
> To my mind the important thing to decide is whether permissive domains
> should be persistent in the policy or not.  If not, then an entry in
> selinuxfs would be appropriate.  If we do want it to be persistent,
> our options include making it a policy primitive, a magic type
> attribute, or an semanage option.  Of those, only the policy primitive
> requires changes to the policy parser.
> 
> I don't have a strong opinion on this myself, though my gut reaction is
> that persistence is a useful property.
> 
>  - todd
They have to be persistent, as I would figure on domains being run in
permissive mode for many months if the chance of the confined domain
going down would be costly.  Personally I would like to put out every
new confined domain in permissive mode for a few weeks until we get out
the bugs in policy. (qemu a couple of weeks ago.)  It would also be
helpful if an administrator could quickly turn a broken domain
permissive rather then putting the entire machine in permissive mode.

I could see the situation of temporarily turning the domain permissive
when the admin suspects SELinux is causing problems with an app, in
order to prove/disprove SELinux is the problem.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkfDPYMACgkQrlYvE4MpobMTJwCdFt5eOlgSJpLY7SvSom5764XX
8r4An0fzWB3477QCF3tfV/iA5w+0dpG5
=TVJo
-----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.

RE: how to implement permissive domains + an old bug

[Stephen Smalley]

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:
> >>> -----BEGIN PGP SIGNED MESSAGE-----
> >>> Hash: SHA1
> >>> 
> >>> Stephen Smalley wrote:
> >>>> On Fri, 2008-02-15 at 15:17 -0500, Joshua Brindle wrote:
> >>>>> Stephen Smalley wrote:
> >>>>>> On Fri, 2008-02-15 at 14:43 -0500, Eric Paris wrote:
> >>>>>>> On Fri, 2008-02-15 at 13:57 -0500, Stephen Smalley wrote:
> >>>>>>>> On Fri, 2008-02-15 at 13:35 -0500, Joshua Brindle wrote:
> >>>>>>>>> Stephen Smalley wrote:
> >>>>>>>>>> On Fri, 2008-02-15 at 12:50 -0500, Eric Paris wrote:
> >>>>>>>>>>> So after many months of trying to avoid it Dan finally beat
> >>>>>>>>>>> me into looking at permissive domains.  I'm coming to the
> >>>>>>>>>>> list to ask how people feel the transfer of knowledge that a
> >>>>>>>>>>> domain is permissive between the policy and the kernel
> >>>>>>>>>>> should be implemented.  (And to point out what I think is a
> >>>>>>>>>>> bug I found while trolling around the code today)
> >>>>>>>>>>> 
> >>>>>>>>>>> Old discussion of permissive domains.
> >>>>>>>>>>> http://marc.info/?l=selinux&m=118953810913436&w=2
> >>>>>>>>>>> 
> >>>>>>>>>>> The basic idea is that we want a domain in which a process
> >>>>>>>>>>> can run without any permission enforcement and without
> >>>>>>>>>>> flooding the audit logs. After much discussion I think
> >>>>>>>>>>> everyone agreed with (or at least stopped arguing against)
> >>>>>>>>>>> a couple of things. 
> >>>>>>>>>>> 
> >>>>>>>>>>> 1) do this in policy (not selinuxfs)
> >>>>>>>>>>> 2) have it act just like 'setenforce 0'
> >>>>>>>>>>> 
> >>>>>>>>>>> My question today is about #1.  How to implement?  Karl
> >>>>>>>>>>> suggested stealing a bit from the type_datum->primary field
> >>>>>>>>>>> to indicate to the kernel that a certain type was a
> >>>>>> permissive domain.  Can I do this?
> >>>>>>>>>>> I guess this is a question for the setools group. Do you
> >>>>>>>>>>> make use of the actual value stored in 'primary'?  The
> >>>>>>>>>>> kernel does not.  Does anything make use of the actual value
> >>>>>>>>>>> outside of the tool chain? Please say 'no' and make this
> >>>>>>>>>>> easier for me. 
> >>>>>>>>>>> 
> >>>>>>>>>>> I want to throw away the 'primary' field all together in the
> >>>>>>>>>>> final binary policy and create a 'new' field called 'flags'
> >>>>>>>>>>> in its place. After my change flags would make use of 2
> >>>>>>>>>>> bits. 
> >>>>>>>>>>> 
> >>>>>>>>>>> #define F_PRIMARY		0x00000001
> >>>>>>>>>>> #define F_PERMISSIVE		0x80000000
> >>>>>>>>>>> if (type_datum->old_primary)
> >>>>>>>>>>> 	type_datum->flags = F_PRIMARY; if (permissive domain)
> >>>>>>>>>>>     type_datum->flags |= F_PERMISSIVE
> >>>>>>>>>>> 
> >>>>>>>>>>> This only works if noone makes actual use of the value in
> >>>>>>>>>>> ->primary. If someone makes use of the value in primary I
> >>>>>>>>>>> can't really reuse that area on disk and I think I'm going
> >>>>>>>>>>> to have to bump the policy version and add a whole new
> >>>>>>>>>>> ->flags field on disk (I don't think pmoore's capability
> >>>>>>>>>>> stuff really helps).
> >>>>>>  Maybe the
> >>>>>>>>>>> tools could just agree to ignore the last bit? To be honest
> >>>>>>>>>>> I'm not personally terribly concerned about setools
> >>>>>>>>>>> backwards compatibility.  I'm really only thinking about
> >>>>>>>>>>> function backwards compatibility, so maybe the tools people
> >>>>>>>>>>> would be ok with me just userping a bit (but I'd much rather
> >>>>>>>>>>> have a more clear 'flags' than 'primary + one bit stolen for
> >>>>>>>>>>> some other random crap).  For backwards compatibility I
> >>>>>>>>>>> might have to bump the policy number even if noone has a
> >>>>>>>>>>> problem with me redefining the meaning of the ->primary
> >>>>>>>>>>> field, not sure yet haven't really wrapped my brain around
> >>>>>>>>>>> it.  I think there is a kernel bug which actually makes it
> >>>>>>>>>>> possible to reuse the field in my new way and maintain
> >>>>>>>>>> backwards kernel compatibility.
> >>>>>>>>>>> **The Bug**
> >>>>>>>>>>> In the binary policy on disk ->primary is a uint32_t but in
> >>>>>>>>>>> the kernel ->primary is an unsigned char.  When we load
> >>>>>>>>>>> policy we just have 
> >>>>>>>>>>> 
> >>>>>>>>>>> typdatum->primary = le32_to_cpu(buf[2]);
> >>>>>>>>>>> 
> >>>>>>>>>>> So we are truncating to 8 bits.  I think that means that if
> >>>>>>>>>>> the on disk ->primary value is greater than 0xFF but the
> >>>>>>>>>>> lower 8 bits are all 0 we are going to screw this up (maybe
> >>>>>>>>>>> this is impossible, but I don't see why looking at libsepol
> >>>>>>>>>>> quickly). Thanks to this bug though I think I could use the
> >>>>>>>>>>> 32nd bit of the on disk representation on old kernels and
> >>>>>>>>>>> they wouldn't even realize it. New kernels could be made to
> >>>>>>>>>>> pay attention to that bit. Backwards compatibility through
> >>>>>>>>>>> bugs, I love it. It also means I don't really want to fix
> >>>>>>>>>>> this bug right now *smile* **End bug**
> >>>>>>>>>> Kernel policy representation only uses ->primary as a boolean
> >>>>>>>>>> flag (is it a primary name or an alias, with the type index
> >>>>>>>>>> value in ->value regardless).  Modular policy introduced the
> >>>>>>>>>> notion of using it to store the primary type index for
> >>>>>>>>>> aliases (when ->flavor == TYPE_ALIAS).  By the time we reach
> >>>>>>>>>> kernel policy (after expansion), it should only be
> > a boolean again.
> >>>>>>> I guess this being done in src/expand.c::type_copy_callback().
> >>>>>>> 
> >>>>>>> All my thought is for nothing though.  Somehow in the language
> >>>>>>> we have to represent permissive domains.  That in and of itself
> >>>>>>> requires a version bump doesn't it?  Drat.
> >>>>>>> 
> >>>>>>> So what format do we want to go with?
> >>>>>>> 
> >>>>>>> permissive httpd_t;
> >>>>>>> 
> >>>>>>> anyone got anything better?
> >>>>>>> 
> >>>>>>> So with the policy version bump should I add a new field,
> >>>>>>> ->flags to the on disk type_datum represenation?  Should I
> >>>>>>> instead just rename ->primary to ->flags and teach libsepol to
> >>>>>>> mask off the flag?  I don't know the toolchain well enough to
> >>>>>>> know if we ever write more than a boolean to disk in ->primary.
> >>>>>>> Guess that's what I'll look for now but first glance tells me I
> >>>>>>> might as well use another 32 bits on disk since it seems as
> >>>>>>> though we have such disperate usage of primary for
> > POLICY_KERNEL vs everything else.
> >>>>>> 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?).

Well, that's an argument for controlling it via selinuxfs rather than
policy, like current enforcing/permissive mode ;)

> 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?
-- 
Stephen Smalley
National Security Agency


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