Mailing List Archive: SELinux Portage and Python2.7

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

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