SELinux Portage and Python2.7

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

SELinux Portage and Python2.7

Robert Sharp

Hi again,

I noticed a bunch of AVCs during my weekly update that look like a shortfall in the portage policy?

For example:

----
time->Wed Dec 14 09:50:23 2016
type=PROCTITLE msg=audit(1481709023.487:245940):
proctitle=707974686F6E322E37002F7573722F6C696236342F707974686F6E322E372F736974652D7061636B616765732F696E636C7564655F7365727665722F696E636C7564655F7365727665722E7079002D2D706F7274002F746D702F6469737463632D70756D702E31676D4479492F736F636B6574002D2D7069645F66696C65002Ftype=PATH msg=audit(1481709023.487:245940): item=1 name="/dev/shm/tmpdC4SvU.include_server-27263-1" inode=4596172 dev=00:13 mode=040700 ouid=250 ogid=250 rdev=00:00 obj=staff_u:object_r:portage_tmpfs_t nametype=CREATE
type=PATH msg=audit(1481709023.487:245940): item=0 name="/dev/shm/" inode=8351 dev=00:13 mode=041777 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tmpfs_t nametype=PARENT
type=CWD msg=audit(1481709023.487:245940):  cwd="/var/tmp/portage/sys-devel/libtool-2.4.6-r2/work/libtool-2.4.6"
type=SYSCALL msg=audit(1481709023.487:245940): arch=c000003e syscall=83 success=yes exit=0 a0=c94da980 a1=1c0 a2=0 a3=1e1 items=2 ppid=27262 pid=27263 auid=4294967295 uid=250 gid=250 euid=250 suid=250 fsuid=250 egid=250 sgid=250 fsgid=250 tty=pts2 ses=4294967295 comm="python2.7" exe="/usr/bin/python2.7" subj=staff_u:sysadm_r:portage_sandbox_t key=(null)
type=AVC msg=audit(1481709023.487:245940): avc:  denied  { create } for  pid=27263 comm="python2.7" name="tmpdC4SvU.include_server-27263-1" scontext=staff_u:sysadm_r:portage_sandbox_t tcontext=staff_u:object_r:portage_tmpfs_t tclass=dir permissive=1

And another AVC:

> type=AVC msg=audit(1481709072.864:245941): avc:  denied  { rmdir } for  pid=27263 comm="python2.7" name="tmpdC4SvU.include_server-27263-1"
> dev="tmpfs" ino=4596172 scontext=staff_u:sysadm_r:portage_sandbox_t tcontext=staff_u:object_r:portage_tmpfs_t tclass=dir permissive=1

Looks like python is trying to create/remove directories within portage_tmpfs_t, and looking at the existing permissions:

> allow portage_sandbox_t portage_tmpfs_t:dir { search read lock getattr write ioctl remove_name open add_name };

suggests that it does not have the necessary permissions (e.g. create)?

Thanks

Robert Sharp

Reply | Threaded
Open this post in threaded view
|

Re: SELinux Portage and Python2.7

Sven Vermeulen
On Wed, Dec 14, 2016 at 06:54:47PM +0000, Robert Sharp wrote:

>    Hi again,
>
>    I noticed a bunch of AVCs during my weekly update that look like a
>    shortfall in the portage policy?
>
>    For example:
>
>    ----
>    time->Wed Dec 14 09:50:23 2016
>    type=PROCTITLE msg=audit(1481709023.487:245940):
>    proctitle=707974686F6E322E37002F7573722F6C696236342F707974686F6E322E372
>    F736974652D7061636B616765732F696E636C7564655F7365727665722F696E636C7564
>    655F7365727665722E7079002D2D706F7274002F746D702F6469737463632D70756D702
>    E31676D4479492F736F636B6574002D2D7069645F66696C65002Ftype=PATH
>    msg=audit(1481709023.487:245940): item=1
>    name="/dev/shm/tmpdC4SvU.include_server-27263-1" inode=4596172
>    dev=00:13 mode=040700 ouid=250 ogid=250 rdev=00:00
>    obj=staff_u:object_r:portage_tmpfs_t nametype=CREATE
[...]

>    type=AVC msg=audit(1481709023.487:245940): avc:  denied  { create }
>    for  pid=27263 comm="python2.7" name="tmpdC4SvU.include_server-27263-1"
>    scontext=staff_u:sysadm_r:portage_sandbox_t
>    tcontext=staff_u:object_r:portage_tmpfs_t tclass=dir permissive=1
>
>    And another AVC:
>
>    > type=AVC msg=audit(1481709072.864:245941): avc:  denied  { rmdir }
>    for  pid=27263 comm="python2.7" name="tmpdC4SvU.include_server-27263-1"
>    > dev="tmpfs" ino=4596172 scontext=staff_u:sysadm_r:portage_sandbox_t
>    tcontext=staff_u:object_r:portage_tmpfs_t tclass=dir permissive=1
>
>    Looks like python is trying to create/remove directories within
>    portage_tmpfs_t, and looking at the existing permissions:
>
>    > allow portage_sandbox_t portage_tmpfs_t:dir { search read lock
>    getattr write ioctl remove_name open add_name };
>
>    suggests that it does not have the necessary permissions (e.g. create)?

I'm a bit weary of granting this. The sandbox domain is meant to be a
sandbox (hence the name), and its current access to portage_tmpfs_t is
already a potential risk (as the portage_tmpfs_t is also used by plain
portage activities, so there is a risk of influencing portage_t by
portage_sandbox_t).

To get things working, I see no problem on your side to allow the
privileges, but we might need to look into the domain separation of the
sandbox domain versus general portage domain(s).

I would personally see if a portage_sandbox_tmpfs_t makes sense, but that
requires much more testing before we just put that in the policies.

Wkr,
        Sven Vermeulen