| 1 |
On Wed, Dec 14, 2016 at 06:54:47PM +0000, Robert Sharp wrote: |
| 2 |
> Hi again, |
| 3 |
> |
| 4 |
> I noticed a bunch of AVCs during my weekly update that look like a |
| 5 |
> shortfall in the portage policy? |
| 6 |
> |
| 7 |
> For example: |
| 8 |
> |
| 9 |
> ---- |
| 10 |
> time->Wed Dec 14 09:50:23 2016 |
| 11 |
> type=PROCTITLE msg=audit(1481709023.487:245940): |
| 12 |
> proctitle=707974686F6E322E37002F7573722F6C696236342F707974686F6E322E372 |
| 13 |
> F736974652D7061636B616765732F696E636C7564655F7365727665722F696E636C7564 |
| 14 |
> 655F7365727665722E7079002D2D706F7274002F746D702F6469737463632D70756D702 |
| 15 |
> E31676D4479492F736F636B6574002D2D7069645F66696C65002Ftype=PATH |
| 16 |
> msg=audit(1481709023.487:245940): item=1 |
| 17 |
> name="/dev/shm/tmpdC4SvU.include_server-27263-1" inode=4596172 |
| 18 |
> dev=00:13 mode=040700 ouid=250 ogid=250 rdev=00:00 |
| 19 |
> obj=staff_u:object_r:portage_tmpfs_t nametype=CREATE |
| 20 |
[...] |
| 21 |
> type=AVC msg=audit(1481709023.487:245940): avc: denied { create } |
| 22 |
> for pid=27263 comm="python2.7" name="tmpdC4SvU.include_server-27263-1" |
| 23 |
> scontext=staff_u:sysadm_r:portage_sandbox_t |
| 24 |
> tcontext=staff_u:object_r:portage_tmpfs_t tclass=dir permissive=1 |
| 25 |
> |
| 26 |
> And another AVC: |
| 27 |
> |
| 28 |
> > type=AVC msg=audit(1481709072.864:245941): avc: denied { rmdir } |
| 29 |
> for pid=27263 comm="python2.7" name="tmpdC4SvU.include_server-27263-1" |
| 30 |
> > dev="tmpfs" ino=4596172 scontext=staff_u:sysadm_r:portage_sandbox_t |
| 31 |
> tcontext=staff_u:object_r:portage_tmpfs_t tclass=dir permissive=1 |
| 32 |
> |
| 33 |
> Looks like python is trying to create/remove directories within |
| 34 |
> portage_tmpfs_t, and looking at the existing permissions: |
| 35 |
> |
| 36 |
> > allow portage_sandbox_t portage_tmpfs_t:dir { search read lock |
| 37 |
> getattr write ioctl remove_name open add_name }; |
| 38 |
> |
| 39 |
> suggests that it does not have the necessary permissions (e.g. create)? |
| 40 |
|
| 41 |
I'm a bit weary of granting this. The sandbox domain is meant to be a |
| 42 |
sandbox (hence the name), and its current access to portage_tmpfs_t is |
| 43 |
already a potential risk (as the portage_tmpfs_t is also used by plain |
| 44 |
portage activities, so there is a risk of influencing portage_t by |
| 45 |
portage_sandbox_t). |
| 46 |
|
| 47 |
To get things working, I see no problem on your side to allow the |
| 48 |
privileges, but we might need to look into the domain separation of the |
| 49 |
sandbox domain versus general portage domain(s). |
| 50 |
|
| 51 |
I would personally see if a portage_sandbox_tmpfs_t makes sense, but that |
| 52 |
requires much more testing before we just put that in the policies. |
| 53 |
|
| 54 |
Wkr, |
| 55 |
Sven Vermeulen |
Archives