Re: SELinux Portage and Python2.7

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