SELinux Userspace Release: 20140826-rc5

SELinux Userspace Release: 20140826-rc5

[Steve Lawrence]

The fifth release candidate for the next release of SELinux Userspace
[1] is now available. The tarballs have been built and can be downloaded
from the Releases wiki page [2]. Changes since rc4 include:

- fixes to libsemanage build system to allow specifying different LIBDIR
and SHLIBDIR directories
- fixes to libselinux and libsepol build system to not assume SHLIBDIR
is ../../ relative to LIBDIR (e.g. now allows LIBIDR == SHLIBDIR)

As with the previous rc, action after installing the release candidate
is required to migrate the policy store from /etc/selinux to
/var/lib/selinux if it has not already been migrated. Detailed
information about this process can be found on the Policy Store
Migration wiki page [3].

Please give this a test and let us know if you find any problems.

Thanks,
- Steve

[1] https://github.com/SELinuxProject/selinux
[2] https://github.com/SELinuxProject/selinux/wiki/Releases
[3] https://github.com/SELinuxProject/selinux/wiki/Policy-Store-Migration

Re: SELinux Userspace Release: 20140826-rc5

[Sven Vermeulen]

On Wed, Oct 29, 2014 at 4:34 PM, Steve Lawrence <slawrence@tresys.com> wrote:
> The fifth release candidate for the next release of SELinux Userspace
> [1] is now available. The tarballs have been built and can be downloaded
> from the Releases wiki page [2]. Changes since rc4 include:
[...]
> Please give this a test and let us know if you find any problems.

Hi Steve

I notice a regression that I can't quite place yet.

I am running with a policy that does not have the unconfined module
loaded (so a strict environment). In the past (same policy, 2.3
utilities) that also prevented those "unconfined domains" to get their
privileges. For instance, initrc_t does not have the
files_unconfined_type assigned to it.

With the 2.4 series, this attribute is assigned to the domain. I
*think* that it is ignoring the gen_require(`type unconfined_t') that
is in unconfined_domain_noaudit() in the sense that the rules that do
not use unconfined_t are now loaded as well. In the past, this would
ignore the entire block.

Wkr,
  Sven Vermeulen

Re: SELinux Userspace Release: 20140826-rc5

[Steve Lawrence]

On 11/02/2014 10:17 AM, Sven Vermeulen wrote:
> On Wed, Oct 29, 2014 at 4:34 PM, Steve Lawrence <slawrence@tresys.com> wrote:
>> The fifth release candidate for the next release of SELinux Userspace
>> [1] is now available. The tarballs have been built and can be downloaded
>> from the Releases wiki page [2]. Changes since rc4 include:
> [...]
>> Please give this a test and let us know if you find any problems.
> 
> Hi Steve
> 
> I notice a regression that I can't quite place yet.
> 
> I am running with a policy that does not have the unconfined module
> loaded (so a strict environment). In the past (same policy, 2.3
> utilities) that also prevented those "unconfined domains" to get their
> privileges. For instance, initrc_t does not have the
> files_unconfined_type assigned to it.
> 
> With the 2.4 series, this attribute is assigned to the domain. I
> *think* that it is ignoring the gen_require(`type unconfined_t') that
> is in unconfined_domain_noaudit() in the sense that the rules that do
> not use unconfined_t are now loaded as well. In the past, this would
> ignore the entire block.
> 

It looks like you are correct, that unconfined_t is the problem. The
unconfined_domain_noaudit interface has a gen_require on unconfined_t.
However, CIL does not have a concept of gen_require. It just tries to
resolve all statements inside an optional block, and if any of them fail
then the optional is disabled. So in refpolicy, this interface depends
on the unconfined_t type, even though it never uses it.

One solution would create a tyepattribute that isn't used in any
statements (and so won't become part of the final kernel policy) but
that types that are gen_required are associated with. This should cause
a failure of the optional without affecting anything alse. Kindof a
hack, and it only works for types/roles since with have attributes for
those, but probably the only way to mimic gen_require in CIL.

Another option would be to change refpolicy so that the unconfined
attributes are defined in the unconfined module rather than in
kernel/domain/fs/etc, but maybe the way unconfined works would make the
difficult. It's also not backwards compatible, so we'd probably still
need the pp change anyway.

- Steve

Re: SELinux Userspace Release: 20140826-rc5

[Sven Vermeulen]

On Mon, Nov 3, 2014 at 2:36 PM, Steve Lawrence <slawrence@tresys.com> wrote:
> It looks like you are correct, that unconfined_t is the problem. The
> unconfined_domain_noaudit interface has a gen_require on unconfined_t.
> However, CIL does not have a concept of gen_require. It just tries to
> resolve all statements inside an optional block, and if any of them fail
> then the optional is disabled. So in refpolicy, this interface depends
> on the unconfined_t type, even though it never uses it.
>
> One solution would create a tyepattribute that isn't used in any
> statements (and so won't become part of the final kernel policy) but
> that types that are gen_required are associated with. This should cause
> a failure of the optional without affecting anything alse. Kindof a
> hack, and it only works for types/roles since with have attributes for
> those, but probably the only way to mimic gen_require in CIL.

Or perhaps inside the optional_policy() block I can define a rule
that, if unconfined was enabled, would be applicable anyway, like so:

allow unconfined_t self:process signal;

(assuming that that is a rule that is applied to unconfined_t - can't
verify it at this moment).

As the unconfined_t isn't defined (unconfined module is not loaded)
then this part blocks as well.

Of course, it's indeed a hack (similar to the typeattribute one).
Having a simple comment above it to make clear that it is to work
around this situation should make it clear.

> Another option would be to change refpolicy so that the unconfined
> attributes are defined in the unconfined module rather than in
> kernel/domain/fs/etc, but maybe the way unconfined works would make the
> difficult. It's also not backwards compatible, so we'd probably still
> need the pp change anyway.

This was actually what I was thinking about implementing on Gentoo to
"fix" this, but might take some time.

Do you have an idea how we could find similar cases? I think the
unconfined ones are the only ones that use such a construction
(gen_require without directly using it) but I rather be certain.

Wkr,
  Sven Vermeulen

Re: SELinux Userspace Release: 20140826-rc5

[James Carter]

On 11/04/2014 01:08 PM, Sven Vermeulen wrote:
> On Mon, Nov 3, 2014 at 2:36 PM, Steve Lawrence <slawrence@tresys.com> wrote:
>> It looks like you are correct, that unconfined_t is the problem. The
>> unconfined_domain_noaudit interface has a gen_require on unconfined_t.
>> However, CIL does not have a concept of gen_require. It just tries to
>> resolve all statements inside an optional block, and if any of them fail
>> then the optional is disabled. So in refpolicy, this interface depends
>> on the unconfined_t type, even though it never uses it.
>>
>> One solution would create a tyepattribute that isn't used in any
>> statements (and so won't become part of the final kernel policy) but
>> that types that are gen_required are associated with. This should cause
>> a failure of the optional without affecting anything alse. Kindof a
>> hack, and it only works for types/roles since with have attributes for
>> those, but probably the only way to mimic gen_require in CIL.
>
> Or perhaps inside the optional_policy() block I can define a rule
> that, if unconfined was enabled, would be applicable anyway, like so:
>
> allow unconfined_t self:process signal;
>
> (assuming that that is a rule that is applied to unconfined_t - can't
> verify it at this moment).
>
> As the unconfined_t isn't defined (unconfined module is not loaded)
> then this part blocks as well.
>
> Of course, it's indeed a hack (similar to the typeattribute one).
> Having a simple comment above it to make clear that it is to work
> around this situation should make it clear.
>

Steve, how hard would it be to keep a list of the types that have been declared 
in the require block and check if they have been used directly? When you reached 
the end of the block any that have not been used could be placed in a rule like 
Sven suggests. Although, I would suggest "allow TYPE self: file getattr;" which 
I know that all domains allow.

>> Another option would be to change refpolicy so that the unconfined
>> attributes are defined in the unconfined module rather than in
>> kernel/domain/fs/etc, but maybe the way unconfined works would make the
>> difficult. It's also not backwards compatible, so we'd probably still
>> need the pp change anyway.
>
> This was actually what I was thinking about implementing on Gentoo to
> "fix" this, but might take some time.
>

We do not need to fix any policy sources. This is an artifact of generating CIL 
from the pp files and is due to the fact that the interfaces have already been 
expanded. In a CIL policy that has been generated from the policy source, if the 
unconfined module is not loaded then the interface unconfined_domain_noaudit() 
does not exist, optional blocks will be disabled as required, and everything works.

Speaking of require block issues. CIL generated from source policy has a problem 
that the CIL generated from pp files does not have. There are a handful of cases 
in the Fedora policy where require blocks in an interface are met because of an 
alias in another module. So these interfaces are expanded and appear in the 
policy even if the modules containing those interfaces are disabled. I currently 
have to manually add these interfaces.

By the way, there is now a fedora branch for the cilpolicy on bitbucket:
https://bitbucket.org/jwcarter/cilpolicy

> Do you have an idea how we could find similar cases? I think the
> unconfined ones are the only ones that use such a construction
> (gen_require without directly using it) but I rather be certain.
>

I seem to remember a few instances in the past were there where typos in the 
require block which caused the block to always be removed. But I don't see that 
in the current policy.


-- 
James Carter <jwcart2@tycho.nsa.gov>
National Security Agency

Re: SELinux Userspace Release: 20140826-rc5

[Steve Lawrence]

On 11/04/2014 03:26 PM, James Carter wrote:
> On 11/04/2014 01:08 PM, Sven Vermeulen wrote:
>> On Mon, Nov 3, 2014 at 2:36 PM, Steve Lawrence <slawrence@tresys.com>
>> wrote:
>>> It looks like you are correct, that unconfined_t is the problem. The
>>> unconfined_domain_noaudit interface has a gen_require on unconfined_t.
>>> However, CIL does not have a concept of gen_require. It just tries to
>>> resolve all statements inside an optional block, and if any of them fail
>>> then the optional is disabled. So in refpolicy, this interface depends
>>> on the unconfined_t type, even though it never uses it.
>>>
>>> One solution would create a tyepattribute that isn't used in any
>>> statements (and so won't become part of the final kernel policy) but
>>> that types that are gen_required are associated with. This should cause
>>> a failure of the optional without affecting anything alse. Kindof a
>>> hack, and it only works for types/roles since with have attributes for
>>> those, but probably the only way to mimic gen_require in CIL.
>>
>> Or perhaps inside the optional_policy() block I can define a rule
>> that, if unconfined was enabled, would be applicable anyway, like so:
>>
>> allow unconfined_t self:process signal;
>>
>> (assuming that that is a rule that is applied to unconfined_t - can't
>> verify it at this moment).
>>
>> As the unconfined_t isn't defined (unconfined module is not loaded)
>> then this part blocks as well.
>>
>> Of course, it's indeed a hack (similar to the typeattribute one).
>> Having a simple comment above it to make clear that it is to work
>> around this situation should make it clear.
>>
> 
> Steve, how hard would it be to keep a list of the types that have been
> declared in the require block and check if they have been used directly?
> When you reached the end of the block any that have not been used could
> be placed in a rule like Sven suggests. 

It probably wouldn't be too difficult to only add statements for types
that aren't used in the optional block. I just finished writing out
gen_requires for everything, regardless of if they are used or not, and
got some interesting numbers. With all the extra gen_require
typeattribute statements (~46000 of them), compiling CIL generated from
refpolicy pp's was actually faster (25 seconds vs 18 seconds). However,
it used about 13MB extra memory (129MB vs 142MB). Not really sure why
there was such a relatively dramatic decrease in compile time though.

I'll look into only adding symbols that are used in the optional and see
if there are noticeable differences, but I suspect performance would be
similar to how it before this change.

> Although, I would suggest "allow
> > TYPE self: file getattr;" which I know that all domains allow

A typeattribute statement would prevent us from having to worry about
this kind of stuff. I was thinking something like this:

In the base module, we would also define this:

  (typeattribute cil_gen_require)

And then in optionals, we could have something like thi:

  (option optional_foo
    (typeattributeset cil_gen_require unconfined_t)
  )

This doesn't change the policy at all (since cil_gen_require isn't used
in any statements, it won't be added to the binary), and a similar idea
can be used for roles as well, though I don't think there are any cases
were roles need to be 'cil_gen_required' in the converted CIL.

>>> Another option would be to change refpolicy so that the unconfined
>>> attributes are defined in the unconfined module rather than in
>>> kernel/domain/fs/etc, but maybe the way unconfined works would make the
>>> difficult. It's also not backwards compatible, so we'd probably still
>>> need the pp change anyway.
>>
>> This was actually what I was thinking about implementing on Gentoo to
>> "fix" this, but might take some time.
>>
> 
> We do not need to fix any policy sources. This is an artifact of
> generating CIL from the pp files and is due to the fact that the
> interfaces have already been expanded. In a CIL policy that has been
> generated from the policy source, if the unconfined module is not loaded
> then the interface unconfined_domain_noaudit() does not exist, optional
> blocks will be disabled as required, and everything works.
> 
> Speaking of require block issues. CIL generated from source policy has a
> problem that the CIL generated from pp files does not have. There are a
> handful of cases in the Fedora policy where require blocks in an
> interface are met because of an alias in another module. So these
> interfaces are expanded and appear in the policy even if the modules
> containing those interfaces are disabled. I currently have to manually
> add these interfaces.
> 
> By the way, there is now a fedora branch for the cilpolicy on bitbucket:
> https://bitbucket.org/jwcarter/cilpolicy
> 
>> Do you have an idea how we could find similar cases? I think the
>> unconfined ones are the only ones that use such a construction
>> (gen_require without directly using it) but I rather be certain.
>>
> 
> I seem to remember a few instances in the past were there where typos in
> the require block which caused the block to always be removed. But I
> don't see that in the current policy.
> 

Testing this, I actually did notice some optional blocks in refpolicy
that are always disabled due to non-existent types/typos. I'll report
those to the refpolicy list.

- Steve

Re: SELinux Userspace Release: 20140826-rc5

[James Carter]

On 11/06/2014 09:12 AM, Steve Lawrence wrote:
> On 11/04/2014 03:26 PM, James Carter wrote:
>> On 11/04/2014 01:08 PM, Sven Vermeulen wrote:
>>> On Mon, Nov 3, 2014 at 2:36 PM, Steve Lawrence <slawrence@tresys.com>
>>> wrote:
>>>> It looks like you are correct, that unconfined_t is the problem. The
>>>> unconfined_domain_noaudit interface has a gen_require on unconfined_t.
>>>> However, CIL does not have a concept of gen_require. It just tries to
>>>> resolve all statements inside an optional block, and if any of them fail
>>>> then the optional is disabled. So in refpolicy, this interface depends
>>>> on the unconfined_t type, even though it never uses it.
>>>>
>>>> One solution would create a tyepattribute that isn't used in any
>>>> statements (and so won't become part of the final kernel policy) but
>>>> that types that are gen_required are associated with. This should cause
>>>> a failure of the optional without affecting anything alse. Kindof a
>>>> hack, and it only works for types/roles since with have attributes for
>>>> those, but probably the only way to mimic gen_require in CIL.
>>>
>>> Or perhaps inside the optional_policy() block I can define a rule
>>> that, if unconfined was enabled, would be applicable anyway, like so:
>>>
>>> allow unconfined_t self:process signal;
>>>
>>> (assuming that that is a rule that is applied to unconfined_t - can't
>>> verify it at this moment).
>>>
>>> As the unconfined_t isn't defined (unconfined module is not loaded)
>>> then this part blocks as well.
>>>
>>> Of course, it's indeed a hack (similar to the typeattribute one).
>>> Having a simple comment above it to make clear that it is to work
>>> around this situation should make it clear.
>>>
>>
>> Steve, how hard would it be to keep a list of the types that have been
>> declared in the require block and check if they have been used directly?
>> When you reached the end of the block any that have not been used could
>> be placed in a rule like Sven suggests.
>
> It probably wouldn't be too difficult to only add statements for types
> that aren't used in the optional block. I just finished writing out
> gen_requires for everything, regardless of if they are used or not, and
> got some interesting numbers. With all the extra gen_require
> typeattribute statements (~46000 of them), compiling CIL generated from
> refpolicy pp's was actually faster (25 seconds vs 18 seconds). However,
> it used about 13MB extra memory (129MB vs 142MB). Not really sure why
> there was such a relatively dramatic decrease in compile time though.
>
> I'll look into only adding symbols that are used in the optional and see
> if there are noticeable differences, but I suspect performance would be
> similar to how it before this change.
>
>> Although, I would suggest "allow
>>> TYPE self: file getattr;" which I know that all domains allow
>
> A typeattribute statement would prevent us from having to worry about
> this kind of stuff. I was thinking something like this:
>
> In the base module, we would also define this:
>
>    (typeattribute cil_gen_require)
>
> And then in optionals, we could have something like thi:
>
>    (option optional_foo
>      (typeattributeset cil_gen_require unconfined_t)
>    )
>
> This doesn't change the policy at all (since cil_gen_require isn't used
> in any statements, it won't be added to the binary), and a similar idea
> can be used for roles as well, though I don't think there are any cases
> were roles need to be 'cil_gen_required' in the converted CIL.
>

You're right. That is the better way of handling this.

Jim



-- 
James Carter <jwcart2@tycho.nsa.gov>
National Security Agency

Re: SELinux Userspace Release: 20140826-rc5

[Sven Vermeulen]

[-- Attachment #1: Type: text/plain, Size: 414 bytes --]

On Oct 29, 2014 4:41 PM, "Steve Lawrence" <slawrence@tresys.com> wrote:
>
> The fifth release candidate for the next release of SELinux Userspace
> [1] is now available.
[...]
> Please give this a test and let us know if you find any problems.

I noticed that the semodule listing command does no longer include the
module version - instead focus is now on the priority. Is this deliberate?

Wkr,
  Sven Vermeulen

[-- Attachment #2: Type: text/html, Size: 580 bytes --]

Re: SELinux Userspace Release: 20140826-rc5

[Steve Lawrence]

On 11/06/2014 01:45 PM, Sven Vermeulen wrote:
> On Oct 29, 2014 4:41 PM, "Steve Lawrence" <slawrence@tresys.com> wrote:
>>
>> The fifth release candidate for the next release of SELinux Userspace
>> [1] is now available.
> [...]
>> Please give this a test and let us know if you find any problems.
> 
> I noticed that the semodule listing command does no longer include the
> module version - instead focus is now on the priority. Is this deliberate?
> 
> Wkr,
>   Sven Vermeulen
> 

Yes, with the move to source policies and high level languages, the
concept of module versions was remove. High level languages may still
provide there own mechanism of module versioning if it makes sense (e.g.
pp modules still have versions in them), but libsemanage no longer uses
these for anything. This is also the reason for deprecating the semodule
--upgrade option.

- Steve