Daemon cannot execute python

Daemon cannot execute python

[Ian Pilcher]

Over the years, I've written several Python-based daemons for my home
network.  I've also written SELinux policies for these daemons.

After a recent CentOS 7 update, which includes
selinux-policy-targeted-3.13.1-266.el7.noarch, these daemons are failing
to start:

   type=AVC msg=audit(1588171416.424:157): avc:  denied  { execute } for
   pid=3359 comm="denatc" path="/usr/bin/python2.7" dev="dm-0"
   ino=12679476 scontext=system_u:system_r:denatc_t:s0
   tcontext=system_u:object_r:bin_t:s0 tclass=file permissive=0

For some reason, these policies worked in the past without including
specific permission to execute bin_t files (something that I'd prefer to
avoid, as it's awfully broad).

Does anyone have any idea what changed (i.e. why did this work before)?

Is there any way to make things work other than giving any Python-based
daemon permission to execute *any* bin_t file?

Thanks!

-- 
========================================================================
                  In Soviet Russia, Google searches you!
========================================================================

Re: Daemon cannot execute python

[Stephen Smalley]

On Wed, Apr 29, 2020 at 12:01 PM Ian Pilcher <arequipeno@gmail.com> wrote:
>
> Over the years, I've written several Python-based daemons for my home
> network.  I've also written SELinux policies for these daemons.
>
> After a recent CentOS 7 update, which includes
> selinux-policy-targeted-3.13.1-266.el7.noarch, these daemons are failing
> to start:
>
>    type=AVC msg=audit(1588171416.424:157): avc:  denied  { execute } for
>    pid=3359 comm="denatc" path="/usr/bin/python2.7" dev="dm-0"
>    ino=12679476 scontext=system_u:system_r:denatc_t:s0
>    tcontext=system_u:object_r:bin_t:s0 tclass=file permissive=0
>
> For some reason, these policies worked in the past without including
> specific permission to execute bin_t files (something that I'd prefer to
> avoid, as it's awfully broad).
>
> Does anyone have any idea what changed (i.e. why did this work before)?
>
> Is there any way to make things work other than giving any Python-based
> daemon permission to execute *any* bin_t file?

Sounds similar to
https://lore.kernel.org/selinux/23A084A9-66A1-4E02-A766-F9214E63A628@nall.com/,
which may be due to a kernel change outside SELinux as per that thread.

It is logically correct since the new domain is executing from the interpreter.
Note that it cannot execve() arbitrary bin_t files without
execute_no_trans permission,
although it can open/mmap PROT_EXEC them with execute permission.

You can reduce the scope by defining and assigning a specific type to
/usr/bin/python2.7
but obviously that will have a rippling impact on the rest of the policy.

Re: Daemon cannot execute python

[Ian Pilcher]

On 4/29/20 11:47 AM, Stephen Smalley wrote:
> Sounds similar to
> https://lore.kernel.org/selinux/23A084A9-66A1-4E02-A766-F9214E63A628@nall.com/,
> which may be due to a kernel change outside SELinux as per that thread.

Yes.  That's exactly it.

> It is logically correct since the new domain is executing from the interpreter.

Indeed.  I was quite puzzled about how it ever worked.

> You can reduce the scope by defining and assigning a specific type to
> /usr/bin/python2.7
> but obviously that will have a rippling impact on the rest of the policy.

That would undoubtedly be painful!  For now, I've modified my systemd
service file to make a copy of the Python executable with the required
context, i.e.:

   [Service]
   Type=simple
   PrivateTmp=true
   ExecStartPre=/usr/bin/cp /usr/bin/python2 /tmp/python.denatc
   ExecStartPre=/usr/bin/chcon -t denatc_exec_t /tmp/python.denatc
   ExecStart=/tmp/python.denatc /usr/local/bin/denatc -d
   ExecStartPost=/usr/bin/rm /tmp/python.denatc

Thanks!

-- 
========================================================================
                  In Soviet Russia, Google searches you!
========================================================================

Re: Daemon cannot execute python

[Ian Pilcher]

On 4/29/20 1:02 PM, Ian Pilcher wrote:
> That would undoubtedly be painful!  For now, I've modified my systemd
> service file to make a copy of the Python executable with the required
> context, i.e.:
> 
>    [Service]
>    Type=simple
>    PrivateTmp=true
>    ExecStartPre=/usr/bin/cp /usr/bin/python2 /tmp/python.denatc
>    ExecStartPre=/usr/bin/chcon -t denatc_exec_t /tmp/python.denatc
>    ExecStart=/tmp/python.denatc /usr/local/bin/denatc -d
>    ExecStartPost=/usr/bin/rm /tmp/python.denatc

Slight update for posterity.  It looks like it's possible to use a
symbolic link, so ...

  [Service]
  Type=simple
  PrivateTmp=true
  ExecStartPre=/usr/bin/ln -s /usr/bin/python2 /tmp/python.denatc
  ExecStartPre=/usr/bin/chcon --reference=/usr/local/bin/denatc 
--no-dereference /tmp/python.denatc
  ExecStart=/tmp/python.denatc /usr/local/bin/denatc -d

(Deleting the copy of the interpreter seems to be racy, so it's
probably best to rely on systemd to delete the whole private temporary
directory.)

-- 
========================================================================
Ian Pilcher                                         arequipeno@gmail.com
-------- "I grew up before Mark Zuckerberg invented friendship" --------
========================================================================

Re: Daemon cannot execute python

[Stephen Smalley]

On Wed, Apr 29, 2020 at 3:25 PM Ian Pilcher <arequipeno@gmail.com> wrote:
>
> On 4/29/20 1:02 PM, Ian Pilcher wrote:
> > That would undoubtedly be painful!  For now, I've modified my systemd
> > service file to make a copy of the Python executable with the required
> > context, i.e.:
> >
> >    [Service]
> >    Type=simple
> >    PrivateTmp=true
> >    ExecStartPre=/usr/bin/cp /usr/bin/python2 /tmp/python.denatc
> >    ExecStartPre=/usr/bin/chcon -t denatc_exec_t /tmp/python.denatc
> >    ExecStart=/tmp/python.denatc /usr/local/bin/denatc -d
> >    ExecStartPost=/usr/bin/rm /tmp/python.denatc
>
> Slight update for posterity.  It looks like it's possible to use a
> symbolic link, so ...
>
>   [Service]
>   Type=simple
>   PrivateTmp=true
>   ExecStartPre=/usr/bin/ln -s /usr/bin/python2 /tmp/python.denatc
>   ExecStartPre=/usr/bin/chcon --reference=/usr/local/bin/denatc
> --no-dereference /tmp/python.denatc
>   ExecStart=/tmp/python.denatc /usr/local/bin/denatc -d

I don't see how that could work.  Symbolic link should be resolved and its
context only ever used to determine whether you could follow/read it.  Not
for the execute check.

Re: Daemon cannot execute python

[Ian Pilcher]

On 4/29/20 3:04 PM, Stephen Smalley wrote:
> On Wed, Apr 29, 2020 at 3:25 PM Ian Pilcher <arequipeno@gmail.com> wrote:
>> Slight update for posterity.  It looks like it's possible to use a
>> symbolic link, so ...
> 
> I don't see how that could work.  Symbolic link should be resolved and its
> context only ever used to determine whether you could follow/read it.  Not
> for the execute check.
> 

I can't speak to how it works, but it does work on CentOS 7.8.  I
suppose it's entirely possible that it would fail on a more up-to-date
distribution.

-- 
========================================================================
                  In Soviet Russia, Google searches you!
========================================================================

Re: Daemon cannot execute python

[Ian Pilcher]

On 4/29/20 6:29 PM, Ian Pilcher wrote:
> On 4/29/20 3:04 PM, Stephen Smalley wrote:
>> On Wed, Apr 29, 2020 at 3:25 PM Ian Pilcher <arequipeno@gmail.com> wrote:
>>> Slight update for posterity.  It looks like it's possible to use a
>>> symbolic link, so ...
>>
>> I don't see how that could work.  Symbolic link should be resolved and 
>> its
>> context only ever used to determine whether you could follow/read it.  
>> Not
>> for the execute check.
>>
> 
> I can't speak to how it works, but it does work on CentOS 7.8.  I
> suppose it's entirely possible that it would fail on a more up-to-date
> distribution.
> 

I was incorrect.  It doesn't work.

The service does start, but it's running as unconfined_service_t (which
makes even less sense to me).  So back to making an actual copy of the
interpreter.

-- 
========================================================================
Ian Pilcher                                         arequipeno@gmail.com
-------- "I grew up before Mark Zuckerberg invented friendship" --------
========================================================================

Re: Daemon cannot execute python

[Stephen Smalley]

On Thu, Apr 30, 2020 at 2:18 AM Ian Pilcher <arequipeno@gmail.com> wrote:
>
> On 4/29/20 6:29 PM, Ian Pilcher wrote:
> > On 4/29/20 3:04 PM, Stephen Smalley wrote:
> >> On Wed, Apr 29, 2020 at 3:25 PM Ian Pilcher <arequipeno@gmail.com> wrote:
> >>> Slight update for posterity.  It looks like it's possible to use a
> >>> symbolic link, so ...
> >>
> >> I don't see how that could work.  Symbolic link should be resolved and
> >> its
> >> context only ever used to determine whether you could follow/read it.
> >> Not
> >> for the execute check.
> >>
> >
> > I can't speak to how it works, but it does work on CentOS 7.8.  I
> > suppose it's entirely possible that it would fail on a more up-to-date
> > distribution.
> >
>
> I was incorrect.  It doesn't work.
>
> The service does start, but it's running as unconfined_service_t (which
> makes even less sense to me).  So back to making an actual copy of the
> interpreter.

That makes sense to me.  The targeted policy in CentOS defaults to
transitioning to unconfined_service_t
for services that lack a specific domain/policy.  The context of the
symbolic link is irrelevant for the execve
because the link is read and resolved to the regular executable file
to which it refers before we even look at its context for
transition purposes, just as with setuid/setgid bits or file capabilities.