virtualenv

virtualenv

[Andrew Holway]

Hello,

We're using virtualenv so we can use weird and wonderful python 
libraries. In the process of writing the SELinux policy module we have 
found that the parent process is in the initrc_t domain rather than the 
desired myapp_t domain.

It seems the virtualenv parent process is not transitioning to the 
nativeapi_t domain because the shell command "source" is not a 
standalone executable therefore we cannot set this with the 
"nativeapi_exec_t" type label. Is there a way around that would be more 
elegant than using some kind of wrapper script?

Its a bit odd to me that the parent process can be in one domain and the 
children in another.

Thanks,

Andrew

        system_u:system_r:initrc_t:s0 4086
/usr/bin/sh -c source /var/lib/myapp/env/bin/activate && gunicorn ...
        system_u:system_r:myapp_t:s0 4091
\_ /var/lib/native-api/env/bin/python /var/lib/myapp/env/bin/gunicorn ...
        system_u:system_r:myapp_t:s0 4176
\_ /var/lib/native-api/env/bin/python 
/var/lib/native-api/env/bin/gunicorn ...

Re: virtualenv

[Stephen Smalley]

On 01/30/2015 11:43 AM, Andrew Holway wrote:
> Hello,
> 
> We're using virtualenv so we can use weird and wonderful python
> libraries. In the process of writing the SELinux policy module we have
> found that the parent process is in the initrc_t domain rather than the
> desired myapp_t domain.
> 
> It seems the virtualenv parent process is not transitioning to the
> nativeapi_t domain because the shell command "source" is not a
> standalone executable therefore we cannot set this with the
> "nativeapi_exec_t" type label. Is there a way around that would be more
> elegant than using some kind of wrapper script?
> 
> Its a bit odd to me that the parent process can be in one domain and the
> children in another.
> 
> Thanks,
> 
> Andrew
> 
>        system_u:system_r:initrc_t:s0 4086
> /usr/bin/sh -c source /var/lib/myapp/env/bin/activate && gunicorn ...
>        system_u:system_r:myapp_t:s0 4091
> \_ /var/lib/native-api/env/bin/python /var/lib/myapp/env/bin/gunicorn ...
>        system_u:system_r:myapp_t:s0 4176
> \_ /var/lib/native-api/env/bin/python
> /var/lib/native-api/env/bin/gunicorn ...

What's the init.d script look like for this service?  If you can prefix
the /usr/bin/sh command with runcon -t myapp_t --, then it should also
run in myapp_t.  But you'll then need to allow myapp_t shell_exec_t:file
entrypoint in your policy.  Is the only domain transition into myapp_t
from initrc_t?

Re: virtualenv

[Andrew Holway]

> What's the init.d script look like for this service?  If you can prefix
> the /usr/bin/sh command with runcon -t myapp_t --, then it should also
> run in myapp_t.  But you'll then need to allow myapp_t shell_exec_t:file
> entrypoint in your policy.  Is the only domain transition into myapp_t
> from initrc_t?

Hi Stephen,

We're using Centos7 and systemd. I guess we can still throw a runcon in 
there. We used the system-config-selinux tool to generate the base 
policy module but the rules it creates are a bit opaque to me.

I think this is the interface that allows initd_t(systemd) to transition 
our app into its domain. I'm a little unsure how I should be making a 
new entrypoint.

        interface(`myapp_domtrans',`
            gen_require(`
                 type myapp_t, myapp_exec_t;
            ')
            corecmd_search_bin($1)
                 domtrans_pattern($1, myapp_exec_t, myapp_t)
        ')


# /usr/lib/systemd/system/myapp.service

[Unit]
Description=MyAPP
After=network.target

[Service]
User=myapp
Group=myapp
ExecStart=/usr/bin/sh -c 'source /var/lib/myapp/env/bin/activate && 
gunicorn --bind 0.0.0.0:8080 --debug --reload wsgi:app'
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s TERM $MAINPID
PrivateTmp=true

[Install]
WantedBy=multi-user.target

Re: virtualenv

[Stephen Smalley]

On 02/04/2015 06:51 AM, Andrew Holway wrote:
> 
>> What's the init.d script look like for this service?  If you can prefix
>> the /usr/bin/sh command with runcon -t myapp_t --, then it should also
>> run in myapp_t.  But you'll then need to allow myapp_t shell_exec_t:file
>> entrypoint in your policy.  Is the only domain transition into myapp_t
>> from initrc_t?
> 
> Hi Stephen,
> 
> We're using Centos7 and systemd. I guess we can still throw a runcon in
> there. We used the system-config-selinux tool to generate the base
> policy module but the rules it creates are a bit opaque to me.
> 
> I think this is the interface that allows initd_t(systemd) to transition
> our app into its domain. I'm a little unsure how I should be making a
> new entrypoint.

The refpolicy interface is domain_entry_file() in domain.if.  Add the
following to your .te file:
domain_entry_file(myapp_t, shell_exec_t)

> 
>        interface(`myapp_domtrans',`
>            gen_require(`
>                 type myapp_t, myapp_exec_t;
>            ')
>            corecmd_search_bin($1)
>                 domtrans_pattern($1, myapp_exec_t, myapp_t)
>        ')
> 
> 
> # /usr/lib/systemd/system/myapp.service
> 
> [Unit]
> Description=MyAPP
> After=network.target
> 
> [Service]
> User=myapp
> Group=myapp
> ExecStart=/usr/bin/sh -c 'source /var/lib/myapp/env/bin/activate &&
> gunicorn --bind 0.0.0.0:8080 --debug --reload wsgi:app'

Insert /usr/bin/runcon -t myapp_t -- before /usr/bin/sh above.  This
will jump into the myapp_t domain before launching the shell, so the
shell and all of its descendants will run in your domain.

> ExecReload=/bin/kill -s HUP $MAINPID
> ExecStop=/bin/kill -s TERM $MAINPID
> PrivateTmp=true
> 
> [Install]
> WantedBy=multi-user.target

Re: virtualenv

[Stephen Smalley]

On 01/30/2015 11:43 AM, Andrew Holway wrote:
> Hello,
> 
> We're using virtualenv so we can use weird and wonderful python
> libraries. In the process of writing the SELinux policy module we have
> found that the parent process is in the initrc_t domain rather than the
> desired myapp_t domain.
> 
> It seems the virtualenv parent process is not transitioning to the
> nativeapi_t domain because the shell command "source" is not a
> standalone executable therefore we cannot set this with the
> "nativeapi_exec_t" type label. Is there a way around that would be more
> elegant than using some kind of wrapper script?
> 
> Its a bit odd to me that the parent process can be in one domain and the
> children in another.

BTW, that's not odd at all - domain transitions normally occur on exec,
so when a parent process does a fork+exec and you have defined a domain
transition in policy on the type assigned to the executable, the child
will run in the new domain, and you'll have parent and child in
different domains.  That's to be expected.