I still think typebounds checking is too tight.

I still think typebounds checking is too tight.

[Daniel J Walsh]

We are now seeing breakage on entrypoint.


If I have a less confined domain and I want to allow unconfined_t to
transition to it, the compiler and the kernel eliminate entrypoints calls.

unconfined_typebounds(svirt_lxc_net_t)

Causes thousands of these errors.

  (allow svirt_lxc_net_t ccs_exec_t (file (entrypoint)))
    <See previous>
  (allow svirt_lxc_net_t canna_initrc_exec_t (file (entrypoint)))
    <See previous>
  (allow svirt_lxc_net_t canna_exec_t (file (entrypoint)))
    <See previous>
  (allow svirt_lxc_net_t callweaver_initrc_exec_t (file (entrypoint)))
    <See previous>
  (allow svirt_lxc_net_t callweaver_exec_t (file (entrypoint)))
    <See previous>
  (allow svirt_lxc_net_t calamaris_exec_t (file (entrypoint)))
    <See previous>
  (allow svirt_lxc_net_t cachefilesd_exec_t (file (entrypoint)))
    <See previous>
  (allow svirt_lxc_net_t bumblebee_exec_t (file (entrypoint)))
    <See previous>

Since svirt_lxc_net_t can be entered via an exec_type.  But unconfined_t
can not.  I think this access should be treated like a target also.

IE Ignored, I don't want to have to allow unconfined_t or docker_t to be
able to be entered by all of the domains that svirt_lxc_net_t could be

entered from.

Re: I still think typebounds checking is too tight.

[Stephen Smalley]

On 07/27/2016 10:14 AM, Daniel J Walsh wrote:
> We are now seeing breakage on entrypoint.
> 
> 
> If I have a less confined domain and I want to allow unconfined_t to
> transition to it, the compiler and the kernel eliminate entrypoints calls.
> 
> unconfined_typebounds(svirt_lxc_net_t)
> 
> Causes thousands of these errors.
> 
>   (allow svirt_lxc_net_t ccs_exec_t (file (entrypoint)))
>     <See previous>
>   (allow svirt_lxc_net_t canna_initrc_exec_t (file (entrypoint)))
>     <See previous>
>   (allow svirt_lxc_net_t canna_exec_t (file (entrypoint)))
>     <See previous>
>   (allow svirt_lxc_net_t callweaver_initrc_exec_t (file (entrypoint)))
>     <See previous>
>   (allow svirt_lxc_net_t callweaver_exec_t (file (entrypoint)))
>     <See previous>
>   (allow svirt_lxc_net_t calamaris_exec_t (file (entrypoint)))
>     <See previous>
>   (allow svirt_lxc_net_t cachefilesd_exec_t (file (entrypoint)))
>     <See previous>
>   (allow svirt_lxc_net_t bumblebee_exec_t (file (entrypoint)))
>     <See previous>
> 
> Since svirt_lxc_net_t can be entered via an exec_type.  But unconfined_t
> can not.  I think this access should be treated like a target also.
> 
> IE Ignored, I don't want to have to allow unconfined_t or docker_t to be
> able to be entered by all of the domains that svirt_lxc_net_t could be
> 
> entered from.

First question: Why does svirt_lxc_net_t need so many entrypoints?
Optimally each domain would only have a single entrypoint type, for the
executable used to initially enter that domain.

Regardless, the correct way to handle this situation is to define a
typebounds on the _exec_t types too, e.g.
typebounds unconfined_exec_t ccs_exec_t;
will cause the first rule above to pass as long as you have:
allow unconfined_t unconfined_exec_t:file entrypoint;
in your policy.

However, you'll need to do this for all of the _exec_t types that are
entrypoints for your domain.

This was case #2 in the typebounds logic in my kernel patch description:
    2. If we have:
        typebounds A B;
        typebounds A_exec B_exec;
    then:
        allow B B_exec:file <permissions>;
    will satisfy the bounds constraint iff:
        allow A A_exec:file <permissions>;
    is also allowed in policy.

    This is essentially the same as #1; it is merely included as
    an example of dealing with object types related to a bounded domain
    in a manner that satisfies the bounds relationship.  Note that
    this approach is preferable to leaving B_exec unbounded and having:
        allow A B_exec:file <permissions>;
    in policy because that would allow B's entrypoints to be used to
    enter A.  Similarly for _tmp or other related types.

Re: I still think typebounds checking is too tight.

[Daniel J Walsh]

On 07/27/2016 11:08 AM, Stephen Smalley wrote:
> On 07/27/2016 10:14 AM, Daniel J Walsh wrote:
>> We are now seeing breakage on entrypoint.
>>
>>
>> If I have a less confined domain and I want to allow unconfined_t to
>> transition to it, the compiler and the kernel eliminate entrypoints calls.
>>
>> unconfined_typebounds(svirt_lxc_net_t)
>>
>> Causes thousands of these errors.
>>
>>   (allow svirt_lxc_net_t ccs_exec_t (file (entrypoint)))
>>     <See previous>
>>   (allow svirt_lxc_net_t canna_initrc_exec_t (file (entrypoint)))
>>     <See previous>
>>   (allow svirt_lxc_net_t canna_exec_t (file (entrypoint)))
>>     <See previous>
>>   (allow svirt_lxc_net_t callweaver_initrc_exec_t (file (entrypoint)))
>>     <See previous>
>>   (allow svirt_lxc_net_t callweaver_exec_t (file (entrypoint)))
>>     <See previous>
>>   (allow svirt_lxc_net_t calamaris_exec_t (file (entrypoint)))
>>     <See previous>
>>   (allow svirt_lxc_net_t cachefilesd_exec_t (file (entrypoint)))
>>     <See previous>
>>   (allow svirt_lxc_net_t bumblebee_exec_t (file (entrypoint)))
>>     <See previous>
>>
>> Since svirt_lxc_net_t can be entered via an exec_type.  But unconfined_t
>> can not.  I think this access should be treated like a target also.
>>
>> IE Ignored, I don't want to have to allow unconfined_t or docker_t to be
>> able to be entered by all of the domains that svirt_lxc_net_t could be
>>
>> entered from.
> First question: Why does svirt_lxc_net_t need so many entrypoints?
> Optimally each domain would only have a single entrypoint type, for the
> executable used to initially enter that domain.
>
> Regardless, the correct way to handle this situation is to define a
> typebounds on the _exec_t types too, e.g.
> typebounds unconfined_exec_t ccs_exec_t;
> will cause the first rule above to pass as long as you have:
> allow unconfined_t unconfined_exec_t:file entrypoint;
> in your policy.
>
> However, you'll need to do this for all of the _exec_t types that are
> entrypoints for your domain.
>
> This was case #2 in the typebounds logic in my kernel patch description:
>     2. If we have:
>         typebounds A B;
>         typebounds A_exec B_exec;
>     then:
>         allow B B_exec:file <permissions>;
>     will satisfy the bounds constraint iff:
>         allow A A_exec:file <permissions>;
>     is also allowed in policy.
>
>     This is essentially the same as #1; it is merely included as
>     an example of dealing with object types related to a bounded domain
>     in a manner that satisfies the bounds relationship.  Note that
>     this approach is preferable to leaving B_exec unbounded and having:
>         allow A B_exec:file <permissions>;
>     in policy because that would allow B's entrypoints to be used to
>     enter A.  Similarly for _tmp or other related types.
>
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
>
>
Reason for container domains to be use exec_type entrypoints was policy
was originally written to allow you to start a container on any
executable in /usr.

Basically we are doing

runcon -t svirt_lxc_net_t /usr/bin/httpd


Can't do
typebounds unconfined_exec_t exec_type;

======================
policy_module(mypol,1.0)

gen_require(`
    type svirt_lxc_net_t;
    attribute entry_type;
    type unconfined_exec_t;
')
unconfined_typebounds(svirt_lxc_net_t)
typebounds unconfined_exec_t entry_type;
========================

# make -f /usr/share/selinux/devel/Makefile
Compiling targeted mypol module
/usr/bin/checkmodule:  loading policy configuration from tmp/mypol.tmp
mypol.te:9:ERROR 'type entry_type is not declared' at token ';' on line
3257:
    
typebounds unconfined_exec_t entry_type;
/usr/bin/checkmodule:  error(s) encountered while parsing configuration
/usr/share/selinux/devel/include/Makefile:154: recipe for target
'tmp/mypol.mod' failed
make: *** [tmp/mypol.mod] Error 1

Re: I still think typebounds checking is too tight.

[Stephen Smalley]

On 07/27/2016 12:52 PM, Daniel J Walsh wrote:
> 
> 
> On 07/27/2016 11:08 AM, Stephen Smalley wrote:
>> On 07/27/2016 10:14 AM, Daniel J Walsh wrote:
>>> We are now seeing breakage on entrypoint.
>>>
>>>
>>> If I have a less confined domain and I want to allow unconfined_t to
>>> transition to it, the compiler and the kernel eliminate entrypoints calls.
>>>
>>> unconfined_typebounds(svirt_lxc_net_t)
>>>
>>> Causes thousands of these errors.
>>>
>>>   (allow svirt_lxc_net_t ccs_exec_t (file (entrypoint)))
>>>     <See previous>
>>>   (allow svirt_lxc_net_t canna_initrc_exec_t (file (entrypoint)))
>>>     <See previous>
>>>   (allow svirt_lxc_net_t canna_exec_t (file (entrypoint)))
>>>     <See previous>
>>>   (allow svirt_lxc_net_t callweaver_initrc_exec_t (file (entrypoint)))
>>>     <See previous>
>>>   (allow svirt_lxc_net_t callweaver_exec_t (file (entrypoint)))
>>>     <See previous>
>>>   (allow svirt_lxc_net_t calamaris_exec_t (file (entrypoint)))
>>>     <See previous>
>>>   (allow svirt_lxc_net_t cachefilesd_exec_t (file (entrypoint)))
>>>     <See previous>
>>>   (allow svirt_lxc_net_t bumblebee_exec_t (file (entrypoint)))
>>>     <See previous>
>>>
>>> Since svirt_lxc_net_t can be entered via an exec_type.  But unconfined_t
>>> can not.  I think this access should be treated like a target also.
>>>
>>> IE Ignored, I don't want to have to allow unconfined_t or docker_t to be
>>> able to be entered by all of the domains that svirt_lxc_net_t could be
>>>
>>> entered from.
>> First question: Why does svirt_lxc_net_t need so many entrypoints?
>> Optimally each domain would only have a single entrypoint type, for the
>> executable used to initially enter that domain.
>>
>> Regardless, the correct way to handle this situation is to define a
>> typebounds on the _exec_t types too, e.g.
>> typebounds unconfined_exec_t ccs_exec_t;
>> will cause the first rule above to pass as long as you have:
>> allow unconfined_t unconfined_exec_t:file entrypoint;
>> in your policy.
>>
>> However, you'll need to do this for all of the _exec_t types that are
>> entrypoints for your domain.
>>
>> This was case #2 in the typebounds logic in my kernel patch description:
>>     2. If we have:
>>         typebounds A B;
>>         typebounds A_exec B_exec;
>>     then:
>>         allow B B_exec:file <permissions>;
>>     will satisfy the bounds constraint iff:
>>         allow A A_exec:file <permissions>;
>>     is also allowed in policy.
>>
>>     This is essentially the same as #1; it is merely included as
>>     an example of dealing with object types related to a bounded domain
>>     in a manner that satisfies the bounds relationship.  Note that
>>     this approach is preferable to leaving B_exec unbounded and having:
>>         allow A B_exec:file <permissions>;
>>     in policy because that would allow B's entrypoints to be used to
>>     enter A.  Similarly for _tmp or other related types.
>>
>> _______________________________________________
>> Selinux mailing list
>> Selinux@tycho.nsa.gov
>> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
>> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
>>
>>
> Reason for container domains to be use exec_type entrypoints was policy
> was originally written to allow you to start a container on any
> executable in /usr.
> 
> Basically we are doing
> 
> runcon -t svirt_lxc_net_t /usr/bin/httpd

Do you still need that or is there a common entrypoint now (even if it
is just a script)?

> 
> Can't do
> typebounds unconfined_exec_t exec_type;
> 
> ======================
> policy_module(mypol,1.0)
> 
> gen_require(`
>     type svirt_lxc_net_t;
>     attribute entry_type;
>     type unconfined_exec_t;
> ')
> unconfined_typebounds(svirt_lxc_net_t)
> typebounds unconfined_exec_t entry_type;
> ========================
> 
> # make -f /usr/share/selinux/devel/Makefile
> Compiling targeted mypol module
> /usr/bin/checkmodule:  loading policy configuration from tmp/mypol.tmp
> mypol.te:9:ERROR 'type entry_type is not declared' at token ';' on line
> 3257:
>     
> typebounds unconfined_exec_t entry_type;
> /usr/bin/checkmodule:  error(s) encountered while parsing configuration
> /usr/share/selinux/devel/include/Makefile:154: recipe for target
> 'tmp/mypol.mod' failed
> make: *** [tmp/mypol.mod] Error 1

Yes, checkpolicy presently only supports specifying an individual child
type for the type bounds.  That said, I don't think it would be hard to
extend checkpolicy to support specifying an attribute for the child type
(but not the parent - that has to be a singleton), and then just set the
parent for all the types in that attribute.  I guess you'd have to
update CIL too.

Re: I still think typebounds checking is too tight.

[Dominick Grift]

[-- Attachment #1.1: Type: text/plain, Size: 5701 bytes --]

On 07/27/2016 07:02 PM, Stephen Smalley wrote:
> On 07/27/2016 12:52 PM, Daniel J Walsh wrote:
>>
>>
>> On 07/27/2016 11:08 AM, Stephen Smalley wrote:
>>> On 07/27/2016 10:14 AM, Daniel J Walsh wrote:
>>>> We are now seeing breakage on entrypoint.
>>>>
>>>>
>>>> If I have a less confined domain and I want to allow unconfined_t to
>>>> transition to it, the compiler and the kernel eliminate entrypoints calls.
>>>>
>>>> unconfined_typebounds(svirt_lxc_net_t)
>>>>
>>>> Causes thousands of these errors.
>>>>
>>>>   (allow svirt_lxc_net_t ccs_exec_t (file (entrypoint)))
>>>>     <See previous>
>>>>   (allow svirt_lxc_net_t canna_initrc_exec_t (file (entrypoint)))
>>>>     <See previous>
>>>>   (allow svirt_lxc_net_t canna_exec_t (file (entrypoint)))
>>>>     <See previous>
>>>>   (allow svirt_lxc_net_t callweaver_initrc_exec_t (file (entrypoint)))
>>>>     <See previous>
>>>>   (allow svirt_lxc_net_t callweaver_exec_t (file (entrypoint)))
>>>>     <See previous>
>>>>   (allow svirt_lxc_net_t calamaris_exec_t (file (entrypoint)))
>>>>     <See previous>
>>>>   (allow svirt_lxc_net_t cachefilesd_exec_t (file (entrypoint)))
>>>>     <See previous>
>>>>   (allow svirt_lxc_net_t bumblebee_exec_t (file (entrypoint)))
>>>>     <See previous>
>>>>
>>>> Since svirt_lxc_net_t can be entered via an exec_type.  But unconfined_t
>>>> can not.  I think this access should be treated like a target also.
>>>>
>>>> IE Ignored, I don't want to have to allow unconfined_t or docker_t to be
>>>> able to be entered by all of the domains that svirt_lxc_net_t could be
>>>>
>>>> entered from.
>>> First question: Why does svirt_lxc_net_t need so many entrypoints?
>>> Optimally each domain would only have a single entrypoint type, for the
>>> executable used to initially enter that domain.
>>>
>>> Regardless, the correct way to handle this situation is to define a
>>> typebounds on the _exec_t types too, e.g.
>>> typebounds unconfined_exec_t ccs_exec_t;
>>> will cause the first rule above to pass as long as you have:
>>> allow unconfined_t unconfined_exec_t:file entrypoint;
>>> in your policy.
>>>
>>> However, you'll need to do this for all of the _exec_t types that are
>>> entrypoints for your domain.
>>>
>>> This was case #2 in the typebounds logic in my kernel patch description:
>>>     2. If we have:
>>>         typebounds A B;
>>>         typebounds A_exec B_exec;
>>>     then:
>>>         allow B B_exec:file <permissions>;
>>>     will satisfy the bounds constraint iff:
>>>         allow A A_exec:file <permissions>;
>>>     is also allowed in policy.
>>>
>>>     This is essentially the same as #1; it is merely included as
>>>     an example of dealing with object types related to a bounded domain
>>>     in a manner that satisfies the bounds relationship.  Note that
>>>     this approach is preferable to leaving B_exec unbounded and having:
>>>         allow A B_exec:file <permissions>;
>>>     in policy because that would allow B's entrypoints to be used to
>>>     enter A.  Similarly for _tmp or other related types.
>>>
>>> _______________________________________________
>>> Selinux mailing list
>>> Selinux@tycho.nsa.gov
>>> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
>>> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
>>>
>>>
>> Reason for container domains to be use exec_type entrypoints was policy
>> was originally written to allow you to start a container on any
>> executable in /usr.
>>
>> Basically we are doing
>>
>> runcon -t svirt_lxc_net_t /usr/bin/httpd
> 
> Do you still need that or is there a common entrypoint now (even if it
> is just a script)?
> 
>>
>> Can't do
>> typebounds unconfined_exec_t exec_type;
>>
>> ======================
>> policy_module(mypol,1.0)
>>
>> gen_require(`
>>     type svirt_lxc_net_t;
>>     attribute entry_type;
>>     type unconfined_exec_t;
>> ')
>> unconfined_typebounds(svirt_lxc_net_t)
>> typebounds unconfined_exec_t entry_type;
>> ========================
>>
>> # make -f /usr/share/selinux/devel/Makefile
>> Compiling targeted mypol module
>> /usr/bin/checkmodule:  loading policy configuration from tmp/mypol.tmp
>> mypol.te:9:ERROR 'type entry_type is not declared' at token ';' on line
>> 3257:
>>     
>> typebounds unconfined_exec_t entry_type;
>> /usr/bin/checkmodule:  error(s) encountered while parsing configuration
>> /usr/share/selinux/devel/include/Makefile:154: recipe for target
>> 'tmp/mypol.mod' failed
>> make: *** [tmp/mypol.mod] Error 1
> 
> Yes, checkpolicy presently only supports specifying an individual child
> type for the type bounds.  That said, I don't think it would be hard to
> extend checkpolicy to support specifying an attribute for the child type
> (but not the parent - that has to be a singleton), and then just set the
> parent for all the types in that attribute.  I guess you'd have to
> update CIL too.
> 
> 

If we want to support this for systemd, then we might as well not beat
around the bush and make systemd unconfined, and make all daemon
processes systemd process bounded subjects, and all daemon executable
files systemd executable file bounded executable files.

> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
> 


-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 648 bytes --]

Re: I still think typebounds checking is too tight.

[Daniel J Walsh]

On 07/27/2016 01:02 PM, Stephen Smalley wrote:
> On 07/27/2016 12:52 PM, Daniel J Walsh wrote:
>>
>> On 07/27/2016 11:08 AM, Stephen Smalley wrote:
>>> On 07/27/2016 10:14 AM, Daniel J Walsh wrote:
>>>> We are now seeing breakage on entrypoint.
>>>>
>>>>
>>>> If I have a less confined domain and I want to allow unconfined_t to
>>>> transition to it, the compiler and the kernel eliminate entrypoints calls.
>>>>
>>>> unconfined_typebounds(svirt_lxc_net_t)
>>>>
>>>> Causes thousands of these errors.
>>>>
>>>>   (allow svirt_lxc_net_t ccs_exec_t (file (entrypoint)))
>>>>     <See previous>
>>>>   (allow svirt_lxc_net_t canna_initrc_exec_t (file (entrypoint)))
>>>>     <See previous>
>>>>   (allow svirt_lxc_net_t canna_exec_t (file (entrypoint)))
>>>>     <See previous>
>>>>   (allow svirt_lxc_net_t callweaver_initrc_exec_t (file (entrypoint)))
>>>>     <See previous>
>>>>   (allow svirt_lxc_net_t callweaver_exec_t (file (entrypoint)))
>>>>     <See previous>
>>>>   (allow svirt_lxc_net_t calamaris_exec_t (file (entrypoint)))
>>>>     <See previous>
>>>>   (allow svirt_lxc_net_t cachefilesd_exec_t (file (entrypoint)))
>>>>     <See previous>
>>>>   (allow svirt_lxc_net_t bumblebee_exec_t (file (entrypoint)))
>>>>     <See previous>
>>>>
>>>> Since svirt_lxc_net_t can be entered via an exec_type.  But unconfined_t
>>>> can not.  I think this access should be treated like a target also.
>>>>
>>>> IE Ignored, I don't want to have to allow unconfined_t or docker_t to be
>>>> able to be entered by all of the domains that svirt_lxc_net_t could be
>>>>
>>>> entered from.
>>> First question: Why does svirt_lxc_net_t need so many entrypoints?
>>> Optimally each domain would only have a single entrypoint type, for the
>>> executable used to initially enter that domain.
>>>
>>> Regardless, the correct way to handle this situation is to define a
>>> typebounds on the _exec_t types too, e.g.
>>> typebounds unconfined_exec_t ccs_exec_t;
>>> will cause the first rule above to pass as long as you have:
>>> allow unconfined_t unconfined_exec_t:file entrypoint;
>>> in your policy.
>>>
>>> However, you'll need to do this for all of the _exec_t types that are
>>> entrypoints for your domain.
>>>
>>> This was case #2 in the typebounds logic in my kernel patch description:
>>>     2. If we have:
>>>         typebounds A B;
>>>         typebounds A_exec B_exec;
>>>     then:
>>>         allow B B_exec:file <permissions>;
>>>     will satisfy the bounds constraint iff:
>>>         allow A A_exec:file <permissions>;
>>>     is also allowed in policy.
>>>
>>>     This is essentially the same as #1; it is merely included as
>>>     an example of dealing with object types related to a bounded domain
>>>     in a manner that satisfies the bounds relationship.  Note that
>>>     this approach is preferable to leaving B_exec unbounded and having:
>>>         allow A B_exec:file <permissions>;
>>>     in policy because that would allow B's entrypoints to be used to
>>>     enter A.  Similarly for _tmp or other related types.
>>>
>>> _______________________________________________
>>> Selinux mailing list
>>> Selinux@tycho.nsa.gov
>>> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
>>> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
>>>
>>>
>> Reason for container domains to be use exec_type entrypoints was policy
>> was originally written to allow you to start a container on any
>> executable in /usr.
>>
>> Basically we are doing
>>
>> runcon -t svirt_lxc_net_t /usr/bin/httpd
> Do you still need that or is there a common entrypoint now (even if it
> is just a script)?
Well I think it is a good feature for containers. To be able to volume
mount in /usr into a container
and then run the process as pid1.

docker run -v /usr:/usr:ro fedora /usr/bin/myapp

Libvirt-lxc relied on this, but it is not used as much.  I kind of like
the idea of just doing this via runcon also.

Speaking of which, I think runcon needs to have a new flag added
--no-new-privs, so that these type bounds get easier
to test.  Another thing needed is a way for seinfo and/or sesearch to
list the type_bounds defined.
>> Can't do
>> typebounds unconfined_exec_t exec_type;
>>
>> ======================
>> policy_module(mypol,1.0)
>>
>> gen_require(`
>>     type svirt_lxc_net_t;
>>     attribute entry_type;
>>     type unconfined_exec_t;
>> ')
>> unconfined_typebounds(svirt_lxc_net_t)
>> typebounds unconfined_exec_t entry_type;
>> ========================
>>
>> # make -f /usr/share/selinux/devel/Makefile
>> Compiling targeted mypol module
>> /usr/bin/checkmodule:  loading policy configuration from tmp/mypol.tmp
>> mypol.te:9:ERROR 'type entry_type is not declared' at token ';' on line
>> 3257:
>>     
>> typebounds unconfined_exec_t entry_type;
>> /usr/bin/checkmodule:  error(s) encountered while parsing configuration
>> /usr/share/selinux/devel/include/Makefile:154: recipe for target
>> 'tmp/mypol.mod' failed
>> make: *** [tmp/mypol.mod] Error 1
> Yes, checkpolicy presently only supports specifying an individual child
> type for the type bounds.  That said, I don't think it would be hard to
> extend checkpolicy to support specifying an attribute for the child type
> (but not the parent - that has to be a singleton), and then just set the
> parent for all the types in that attribute.  I guess you'd have to
> update CIL too.
>
>
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
>
>

Re: I still think typebounds checking is too tight.

[Stephen Smalley]

On 07/27/2016 12:52 PM, Daniel J Walsh wrote:
> 
> 
> On 07/27/2016 11:08 AM, Stephen Smalley wrote:
>> On 07/27/2016 10:14 AM, Daniel J Walsh wrote:
>>> We are now seeing breakage on entrypoint.
>>>
>>>
>>> If I have a less confined domain and I want to allow unconfined_t to
>>> transition to it, the compiler and the kernel eliminate entrypoints calls.
>>>
>>> unconfined_typebounds(svirt_lxc_net_t)
>>>
>>> Causes thousands of these errors.
>>>
>>>   (allow svirt_lxc_net_t ccs_exec_t (file (entrypoint)))
>>>     <See previous>
>>>   (allow svirt_lxc_net_t canna_initrc_exec_t (file (entrypoint)))
>>>     <See previous>
>>>   (allow svirt_lxc_net_t canna_exec_t (file (entrypoint)))
>>>     <See previous>
>>>   (allow svirt_lxc_net_t callweaver_initrc_exec_t (file (entrypoint)))
>>>     <See previous>
>>>   (allow svirt_lxc_net_t callweaver_exec_t (file (entrypoint)))
>>>     <See previous>
>>>   (allow svirt_lxc_net_t calamaris_exec_t (file (entrypoint)))
>>>     <See previous>
>>>   (allow svirt_lxc_net_t cachefilesd_exec_t (file (entrypoint)))
>>>     <See previous>
>>>   (allow svirt_lxc_net_t bumblebee_exec_t (file (entrypoint)))
>>>     <See previous>
>>>
>>> Since svirt_lxc_net_t can be entered via an exec_type.  But unconfined_t
>>> can not.  I think this access should be treated like a target also.
>>>
>>> IE Ignored, I don't want to have to allow unconfined_t or docker_t to be
>>> able to be entered by all of the domains that svirt_lxc_net_t could be
>>>
>>> entered from.
>> First question: Why does svirt_lxc_net_t need so many entrypoints?
>> Optimally each domain would only have a single entrypoint type, for the
>> executable used to initially enter that domain.
>>
>> Regardless, the correct way to handle this situation is to define a
>> typebounds on the _exec_t types too, e.g.
>> typebounds unconfined_exec_t ccs_exec_t;
>> will cause the first rule above to pass as long as you have:
>> allow unconfined_t unconfined_exec_t:file entrypoint;
>> in your policy.
>>
>> However, you'll need to do this for all of the _exec_t types that are
>> entrypoints for your domain.
>>
>> This was case #2 in the typebounds logic in my kernel patch description:
>>     2. If we have:
>>         typebounds A B;
>>         typebounds A_exec B_exec;
>>     then:
>>         allow B B_exec:file <permissions>;
>>     will satisfy the bounds constraint iff:
>>         allow A A_exec:file <permissions>;
>>     is also allowed in policy.
>>
>>     This is essentially the same as #1; it is merely included as
>>     an example of dealing with object types related to a bounded domain
>>     in a manner that satisfies the bounds relationship.  Note that
>>     this approach is preferable to leaving B_exec unbounded and having:
>>         allow A B_exec:file <permissions>;
>>     in policy because that would allow B's entrypoints to be used to
>>     enter A.  Similarly for _tmp or other related types.
>>
>> _______________________________________________
>> Selinux mailing list
>> Selinux@tycho.nsa.gov
>> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
>> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
>>
>>
> Reason for container domains to be use exec_type entrypoints was policy
> was originally written to allow you to start a container on any
> executable in /usr.
> 
> Basically we are doing
> 
> runcon -t svirt_lxc_net_t /usr/bin/httpd
> 
> 
> Can't do
> typebounds unconfined_exec_t exec_type;
> 
> ======================
> policy_module(mypol,1.0)
> 
> gen_require(`
>     type svirt_lxc_net_t;
>     attribute entry_type;
>     type unconfined_exec_t;
> ')
> unconfined_typebounds(svirt_lxc_net_t)
> typebounds unconfined_exec_t entry_type;
> ========================
> 
> # make -f /usr/share/selinux/devel/Makefile
> Compiling targeted mypol module
> /usr/bin/checkmodule:  loading policy configuration from tmp/mypol.tmp
> mypol.te:9:ERROR 'type entry_type is not declared' at token ';' on line
> 3257:
>     
> typebounds unconfined_exec_t entry_type;
> /usr/bin/checkmodule:  error(s) encountered while parsing configuration
> /usr/share/selinux/devel/include/Makefile:154: recipe for target
> 'tmp/mypol.mod' failed
> make: *** [tmp/mypol.mod] Error 1

In the meantime, can't you work around this by adding a typebounds
unconfined_exec_t $1; to wherever you currently have typeattribute $1
entry_type;?

Re: I still think typebounds checking is too tight.

[Daniel J Walsh]

On 07/27/2016 02:01 PM, Stephen Smalley wrote:
> On 07/27/2016 12:52 PM, Daniel J Walsh wrote:
>>
>> On 07/27/2016 11:08 AM, Stephen Smalley wrote:
>>> On 07/27/2016 10:14 AM, Daniel J Walsh wrote:
>>>> We are now seeing breakage on entrypoint.
>>>>
>>>>
>>>> If I have a less confined domain and I want to allow unconfined_t to
>>>> transition to it, the compiler and the kernel eliminate entrypoints calls.
>>>>
>>>> unconfined_typebounds(svirt_lxc_net_t)
>>>>
>>>> Causes thousands of these errors.
>>>>
>>>>   (allow svirt_lxc_net_t ccs_exec_t (file (entrypoint)))
>>>>     <See previous>
>>>>   (allow svirt_lxc_net_t canna_initrc_exec_t (file (entrypoint)))
>>>>     <See previous>
>>>>   (allow svirt_lxc_net_t canna_exec_t (file (entrypoint)))
>>>>     <See previous>
>>>>   (allow svirt_lxc_net_t callweaver_initrc_exec_t (file (entrypoint)))
>>>>     <See previous>
>>>>   (allow svirt_lxc_net_t callweaver_exec_t (file (entrypoint)))
>>>>     <See previous>
>>>>   (allow svirt_lxc_net_t calamaris_exec_t (file (entrypoint)))
>>>>     <See previous>
>>>>   (allow svirt_lxc_net_t cachefilesd_exec_t (file (entrypoint)))
>>>>     <See previous>
>>>>   (allow svirt_lxc_net_t bumblebee_exec_t (file (entrypoint)))
>>>>     <See previous>
>>>>
>>>> Since svirt_lxc_net_t can be entered via an exec_type.  But unconfined_t
>>>> can not.  I think this access should be treated like a target also.
>>>>
>>>> IE Ignored, I don't want to have to allow unconfined_t or docker_t to be
>>>> able to be entered by all of the domains that svirt_lxc_net_t could be
>>>>
>>>> entered from.
>>> First question: Why does svirt_lxc_net_t need so many entrypoints?
>>> Optimally each domain would only have a single entrypoint type, for the
>>> executable used to initially enter that domain.
>>>
>>> Regardless, the correct way to handle this situation is to define a
>>> typebounds on the _exec_t types too, e.g.
>>> typebounds unconfined_exec_t ccs_exec_t;
>>> will cause the first rule above to pass as long as you have:
>>> allow unconfined_t unconfined_exec_t:file entrypoint;
>>> in your policy.
>>>
>>> However, you'll need to do this for all of the _exec_t types that are
>>> entrypoints for your domain.
>>>
>>> This was case #2 in the typebounds logic in my kernel patch description:
>>>     2. If we have:
>>>         typebounds A B;
>>>         typebounds A_exec B_exec;
>>>     then:
>>>         allow B B_exec:file <permissions>;
>>>     will satisfy the bounds constraint iff:
>>>         allow A A_exec:file <permissions>;
>>>     is also allowed in policy.
>>>
>>>     This is essentially the same as #1; it is merely included as
>>>     an example of dealing with object types related to a bounded domain
>>>     in a manner that satisfies the bounds relationship.  Note that
>>>     this approach is preferable to leaving B_exec unbounded and having:
>>>         allow A B_exec:file <permissions>;
>>>     in policy because that would allow B's entrypoints to be used to
>>>     enter A.  Similarly for _tmp or other related types.
>>>
>>> _______________________________________________
>>> Selinux mailing list
>>> Selinux@tycho.nsa.gov
>>> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
>>> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
>>>
>>>
>> Reason for container domains to be use exec_type entrypoints was policy
>> was originally written to allow you to start a container on any
>> executable in /usr.
>>
>> Basically we are doing
>>
>> runcon -t svirt_lxc_net_t /usr/bin/httpd
>>
>>
>> Can't do
>> typebounds unconfined_exec_t exec_type;
>>
>> ======================
>> policy_module(mypol,1.0)
>>
>> gen_require(`
>>     type svirt_lxc_net_t;
>>     attribute entry_type;
>>     type unconfined_exec_t;
>> ')
>> unconfined_typebounds(svirt_lxc_net_t)
>> typebounds unconfined_exec_t entry_type;
>> ========================
>>
>> # make -f /usr/share/selinux/devel/Makefile
>> Compiling targeted mypol module
>> /usr/bin/checkmodule:  loading policy configuration from tmp/mypol.tmp
>> mypol.te:9:ERROR 'type entry_type is not declared' at token ';' on line
>> 3257:
>>     
>> typebounds unconfined_exec_t entry_type;
>> /usr/bin/checkmodule:  error(s) encountered while parsing configuration
>> /usr/share/selinux/devel/include/Makefile:154: recipe for target
>> 'tmp/mypol.mod' failed
>> make: *** [tmp/mypol.mod] Error 1
> In the meantime, can't you work around this by adding a typebounds
> unconfined_exec_t $1; to wherever you currently have typeattribute $1
> entry_type;?
>
>
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
>
>
Yes that would work.