Mailing List Archive

Portage-related AVCs
Hi,

just done my weekly update and I noticed the following AVCs occurred
that suggest something missing in the portage policy?

type=PROCTITLE msg=audit(1479900756.052:3548):
proctitle=6370002D61002D2D7265666C696E6B3D6175746F002F7661722F746D702F706F72746167652F6465762D707974686F6E2F70797061782D302E392E322F696D6167652F5F707974686F6E322E372F2E002F7661722F746D702F706F72746167652F6465762D707974686F6E2F70797061782D302E392E322F696D6167652F2F
type=PATH msg=audit(1479900756.052:3548): item=0
name="/var/tmp/portage/dev-python/pypax-0.9.2/image/." inode=1182893
dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00
obj=staff_u:object_r:portage_tmp_t nametype=NORMAL
type=CWD msg=audit(1479900756.052:3548):
cwd="/var/tmp/portage/dev-python/pypax-0.9.2/work/elfix-0.9.2/scripts"
type=SYSCALL msg=audit(1479900756.052:3548): arch=c000003e syscall=189
success=yes exit=0 a0=44b69d9c40 a1=36fe2f5a763 a2=44b69d9df0 a3=1f
items=1 ppid=21441 pid=21661 auid=4294967295 uid=0 gid=0 euid=0 suid=0
fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="cp"
exe="/bin/cp" subj=staff_u:sysadm_r:portage_sandbox_t key=(null)
type=AVC msg=audit(1479900756.052:3548): avc: denied { relabelto }
for pid=21661 comm="cp" name="image" dev="dm-0" ino=1182893
scontext=staff_u:sysadm_r:portage_sandbox_t
tcontext=staff_u:object_r:portage_tmp_t tclass=dir permissive=1
type=AVC msg=audit(1479900756.052:3548): avc: denied { relabelfrom }
for pid=21661 comm="cp" name="image" dev="dm-0" ino=1182893
scontext=staff_u:sysadm_r:portage_sandbox_t
tcontext=staff_u:object_r:portage_tmp_t tclass=dir permissive=1

I checked the policy for source=portage_sandbox_t and
target=portage_tmp_t and it is:

# sesearch -s portage_sandbox_t -t portage_tmp_t -Ad
Found 5 semantic av rules:
allow portage_sandbox_t portage_tmp_t : lnk_file { ioctl read write
create getattr setattr lock unlink link rename } ;
allow portage_sandbox_t portage_tmp_t : dir { ioctl read write
create getattr setattr lock unlink link rename add_name remove_name
reparent search rmdir open } ;
allow portage_sandbox_t portage_tmp_t : fifo_file { ioctl read write
create getattr setattr lock append unlink link rename open } ;
allow portage_sandbox_t portage_tmp_t : file { ioctl read write
create getattr setattr lock relabelfrom relabelto append unlink link
rename execute execute_no_trans open } ;
allow portage_sandbox_t portage_tmp_t : sock_file { ioctl read write
create getattr setattr lock append unlink link rename open } ;

It looks to me like portage was trying to relabelto/from a directory but
these ops are only allowed for files?

I also spotted AVCs involving directory access to portage_tmpfs_t (and
sandbox as the source), such as:

type=PROCTITLE msg=audit(1479900586.938:3542):
proctitle=707974686F6E322E37002F7573722F6C696236342F707974686F6E322E372F736974652D7061636B616765732F696E636C7564655F7365727665722F696E636C7564655F7365727665722E7079002D2D706F7274002F746D702F6469737463632D70756D702E656B6A3330372F736F636B6574002D2D7069645F66696C65002F
type=PATH msg=audit(1479900586.938:3542): item=1
name="/dev/shm/tmpgk84Lo.include_server-16244-1" inode=1246573 dev=00:13
mode=040700 ouid=250 ogid=250 rdev=00:00
obj=staff_u:object_r:portage_tmpfs_t nametype=DELETE
type=PATH msg=audit(1479900586.938:3542): 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(1479900586.938:3542):
cwd="/var/tmp/portage/dev-python/cffi-1.5.2/work/cffi-1.5.2"
type=SYSCALL msg=audit(1479900586.938:3542): arch=c000003e syscall=84
success=yes exit=0 a0=3a6d7c7770 a1=0 a2=0 a3=36b items=2 ppid=1
pid=16244 auid=4294967295 uid=250 gid=250 euid=250 suid=250 fsuid=250
egid=250 sgid=250 fsgid=250 tty=pts0 ses=4294967295 comm="python2.7"
exe="/usr/bin/python2.7" subj=staff_u:sysadm_r:portage_sandbox_t key=(null)
type=AVC msg=audit(1479900586.938:3542): avc: denied { rmdir } for
pid=16244 comm="python2.7" name="tmpgk84Lo.include_server-16244-1"
dev="tmpfs" ino=1246573 scontext=staff_u:sysadm_r:portage_sandbox_t
tcontext=staff_u:object_r:portage_tmpfs_t tclass=dir permissive=1

And a similar AVC for creating the same directory.

Is this likely to be a policy gap or have I done something wrong or
failed to do something I should have. I cannot provide more details
about what was happening at the time, other than in the audit snippets
above - it was the middle of a lengthy update process.

Thanks,

Robert Sharp
Re: Portage-related AVCs [ In reply to ]
On Wed, Nov 23, 2016 at 12:58:34PM +0000, Robert Sharp wrote:
> Hi,
>
> just done my weekly update and I noticed the following AVCs occurred
> that suggest something missing in the portage policy?
>
> type=PROCTITLE msg=audit(1479900756.052:3548):
> proctitle=6370002D61002D2D7265666C696E6B3D6175746F002F7661722F746D702F706F72746167652F6465762D707974686F6E2F70797061782D302E392E322F696D6167652F5F707974686F6E322E372F2E002F7661722F746D702F706F72746167652F6465762D707974686F6E2F70797061782D302E392E322F696D6167652F2F
> type=PATH msg=audit(1479900756.052:3548): item=0
> name="/var/tmp/portage/dev-python/pypax-0.9.2/image/." inode=1182893
> dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00
> obj=staff_u:object_r:portage_tmp_t nametype=NORMAL
> type=CWD msg=audit(1479900756.052:3548):
> cwd="/var/tmp/portage/dev-python/pypax-0.9.2/work/elfix-0.9.2/scripts"
> type=SYSCALL msg=audit(1479900756.052:3548): arch=c000003e syscall=189
> success=yes exit=0 a0=44b69d9c40 a1=36fe2f5a763 a2=44b69d9df0 a3=1f
> items=1 ppid=21441 pid=21661 auid=4294967295 uid=0 gid=0 euid=0 suid=0
> fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="cp"
> exe="/bin/cp" subj=staff_u:sysadm_r:portage_sandbox_t key=(null)
> type=AVC msg=audit(1479900756.052:3548): avc: denied { relabelto }
> for pid=21661 comm="cp" name="image" dev="dm-0" ino=1182893
> scontext=staff_u:sysadm_r:portage_sandbox_t
> tcontext=staff_u:object_r:portage_tmp_t tclass=dir permissive=1
> type=AVC msg=audit(1479900756.052:3548): avc: denied { relabelfrom }
> for pid=21661 comm="cp" name="image" dev="dm-0" ino=1182893
> scontext=staff_u:sysadm_r:portage_sandbox_t
> tcontext=staff_u:object_r:portage_tmp_t tclass=dir permissive=1
>
> I checked the policy for source=portage_sandbox_t and
> target=portage_tmp_t and it is:
>
> # sesearch -s portage_sandbox_t -t portage_tmp_t -Ad
> Found 5 semantic av rules:
> allow portage_sandbox_t portage_tmp_t : lnk_file { ioctl read write
> create getattr setattr lock unlink link rename } ;
> allow portage_sandbox_t portage_tmp_t : dir { ioctl read write
> create getattr setattr lock unlink link rename add_name remove_name
> reparent search rmdir open } ;
> allow portage_sandbox_t portage_tmp_t : fifo_file { ioctl read write
> create getattr setattr lock append unlink link rename open } ;
> allow portage_sandbox_t portage_tmp_t : file { ioctl read write
> create getattr setattr lock relabelfrom relabelto append unlink link
> rename execute execute_no_trans open } ;
> allow portage_sandbox_t portage_tmp_t : sock_file { ioctl read write
> create getattr setattr lock append unlink link rename open } ;
>
> It looks to me like portage was trying to relabelto/from a directory but
> these ops are only allowed for files?

I've definitely got perms towards dirs too.
# sesearch -s portage_sandbox_t -t portage_tmp_t -A
allow portage_sandbox_t non_auth_file_type:dir { open search getattr read lock ioctl };
allow portage_sandbox_t non_auth_file_type:file { getattr read open lock ioctl };
allow portage_sandbox_t non_auth_file_type:lnk_file { read getattr };
allow portage_sandbox_t portage_tmp_t:dir { add_name link remove_name unlink write open relabelfrom search getattr rename read lock reparent create rmdir setattr relabelto ioctl };
allow portage_sandbox_t portage_tmp_t:fifo_file { link append unlink write open getattr rename read lock create setattr ioctl };
allow portage_sandbox_t portage_tmp_t:file { link append unlink write open relabelfrom getattr rename read lock execute_no_trans create execute setattr relabelto ioctl };
allow portage_sandbox_t portage_tmp_t:lnk_file { link unlink write getattr rename read lock create setattr ioctl };
allow portage_sandbox_t portage_tmp_t:sock_file { link append unlink write open getattr rename read lock create setattr ioctl };

Are you on ~arch or stable? did you just upgrade to the 2.6 userland?
What versions do you have installed of these:
sys-libs/libsepol
sys-libs/libselinux
sys-libs/libsemanage
sys-apps/checkpolicy
sys-apps/policycoreutils
dev-python/sepolgen
app-admin/setools

what does this return?
ls -al /etc/selinux/*/policy/policy.*

and in /etc/selinux/semanage.conf, do you have policy-version = set to anything?

-- Jason

> I also spotted AVCs involving directory access to portage_tmpfs_t (and
> sandbox as the source), such as:
>
> type=PROCTITLE msg=audit(1479900586.938:3542):
> proctitle=707974686F6E322E37002F7573722F6C696236342F707974686F6E322E372F736974652D7061636B616765732F696E636C7564655F7365727665722F696E636C7564655F7365727665722E7079002D2D706F7274002F746D702F6469737463632D70756D702E656B6A3330372F736F636B6574002D2D7069645F66696C65002F
> type=PATH msg=audit(1479900586.938:3542): item=1
> name="/dev/shm/tmpgk84Lo.include_server-16244-1" inode=1246573 dev=00:13
> mode=040700 ouid=250 ogid=250 rdev=00:00
> obj=staff_u:object_r:portage_tmpfs_t nametype=DELETE
> type=PATH msg=audit(1479900586.938:3542): 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(1479900586.938:3542):
> cwd="/var/tmp/portage/dev-python/cffi-1.5.2/work/cffi-1.5.2"
> type=SYSCALL msg=audit(1479900586.938:3542): arch=c000003e syscall=84
> success=yes exit=0 a0=3a6d7c7770 a1=0 a2=0 a3=36b items=2 ppid=1
> pid=16244 auid=4294967295 uid=250 gid=250 euid=250 suid=250 fsuid=250
> egid=250 sgid=250 fsgid=250 tty=pts0 ses=4294967295 comm="python2.7"
> exe="/usr/bin/python2.7" subj=staff_u:sysadm_r:portage_sandbox_t key=(null)
> type=AVC msg=audit(1479900586.938:3542): avc: denied { rmdir } for
> pid=16244 comm="python2.7" name="tmpgk84Lo.include_server-16244-1"
> dev="tmpfs" ino=1246573 scontext=staff_u:sysadm_r:portage_sandbox_t
> tcontext=staff_u:object_r:portage_tmpfs_t tclass=dir permissive=1
>
> And a similar AVC for creating the same directory.
>
> Is this likely to be a policy gap or have I done something wrong or
> failed to do something I should have. I cannot provide more details
> about what was happening at the time, other than in the audit snippets
> above - it was the middle of a lengthy update process.
>
> Thanks,
>
> Robert Sharp
>
Re: Portage-related AVCs [ In reply to ]
On 23/11/16 14:37, Jason Zaman wrote:
> Are you on ~arch or stable? did you just upgrade to the 2.6 userland?
> What versions do you have installed of these:
> sys-libs/libsepol
> sys-libs/libselinux
> sys-libs/libsemanage
> sys-apps/checkpolicy
> sys-apps/policycoreutils
> dev-python/sepolgen
> app-admin/setools
Looks like I am stable - 2.5 for all of the above.
>
> what does this return?
> ls -al/etc/selinux/*/policy/policy.*
-rw-r--r--. 1 root root 433338 Apr 6 2016
/etc/selinux/strict/policy/policy.29
-rw-r--r--. 1 root root 445097 Nov 23 11:43
/etc/selinux/strict/policy/policy.30
-rw-r--r--. 1 root root 450378 Apr 6 2016
/etc/selinux/targeted/policy/policy.29
-rw-r--r--. 1 root root 462377 Nov 23 11:43
/etc/selinux/targeted/policy/policy.30
> and in /etc/selinux/semanage.conf, do you have policy-version = set to anything?
module-store = direct
save-linked=false
expand-check=1
bzip-blocksize=0
bzip-small=true

so no for the last one!

Should I move to ~arch then, and is there a guide for that or is it
fairly simple?

Thanks,
Robert
Re: Portage-related AVCs [ In reply to ]
On Wed, Nov 23, 2016 at 03:16:44PM +0000, Robert Sharp wrote:
>
> On 23/11/16 14:37, Jason Zaman wrote:
> > Are you on ~arch or stable? did you just upgrade to the 2.6 userland?
> > What versions do you have installed of these:
> > sys-libs/libsepol
> > sys-libs/libselinux
> > sys-libs/libsemanage
> > sys-apps/checkpolicy
> > sys-apps/policycoreutils
> > dev-python/sepolgen
> > app-admin/setools
> Looks like I am stable - 2.5 for all of the above.
> >
> > what does this return?
> > ls -al/etc/selinux/*/policy/policy.*
> -rw-r--r--. 1 root root 433338 Apr 6 2016
> /etc/selinux/strict/policy/policy.29
> -rw-r--r--. 1 root root 445097 Nov 23 11:43
> /etc/selinux/strict/policy/policy.30
> -rw-r--r--. 1 root root 450378 Apr 6 2016
> /etc/selinux/targeted/policy/policy.29
> -rw-r--r--. 1 root root 462377 Nov 23 11:43
> /etc/selinux/targeted/policy/policy.30
> > and in /etc/selinux/semanage.conf, do you have policy-version = set to anything?
> module-store = direct
> save-linked=false
> expand-check=1
> bzip-blocksize=0
> bzip-small=true
>
> so no for the last one!
>
> Should I move to ~arch then, and is there a guide for that or is it
> fairly simple?
>
> Thanks,
> Robert

Okay so the problem is the two different policy versions. Some versions
ago the kernel added policy version 30. By default the userspace will
load in the highest version that exists (ie
/etc/selinux/strict/policy/policy.30). setools4 supports that version
just fine, the old setools3 only supported up to policy version 29.
your sesearch line is probably searching the old .29 one or something so
its weird.

Two ways to proceed:
1) downgrade to policy.29:
- Add policy-version = 29 to semanage.conf
- rm /etc/selinux/*/policy/policy.30
- semodule -B

If that is not enough, you can completely rebuild all the policy
packages with: emerge @selinux-rebuild

2) stick with policy.30 and upgrade the tools so it works properly.
- Add this to package.keywords:
sys-libs/libsepol ~amd64
sys-libs/libselinux ~amd64
sys-libs/libsemanage ~amd64
sys-apps/checkpolicy ~amd64
sys-apps/policycoreutils ~amd64
dev-python/sepolgen ~amd64
app-admin/setools ~amd64

- emerge -avDu @world
- rm /etc/selinux/*/policy/policy.29
- semodule -B

(You can again do emerge @selinux-rebuild if you want)

Either is fine, but im probably just gonna stabilize the 2.6 userspace
in a couple weeks so that one is likely easier. and setools4 is waaay
better than 3. The important point is that you dont want to have both
policy.29 and policy.30 around. Then you get weirdness like if you
downgrade a kernel or something random it'll load in the old policy
which probably doesnt work properly, so whichever you pick, make sure
you nuke the other one. and semodule -B will rebuild the whole policy
again and load it.

-- Jason
Re: Portage-related AVCs [ In reply to ]
On 23/11/16 15:58, Jason Zaman wrote:
> Either is fine, but im probably just gonna stabilize the 2.6 userspace
> in a couple weeks so that one is likely easier. and setools4 is waaay
> better than 3. The important point is that you dont want to have both
> policy.29 and policy.30 around. Then you get weirdness like if you
> downgrade a kernel or something random it'll load in the old policy
> which probably doesnt work properly, so whichever you pick, make sure
> you nuke the other one. and semodule -B will rebuild the whole policy
> again and load it.
OK - I will go with policy.30 and add the keywords etc. I did a couple
of local policy changes that may not be needed so will they disappear in
all of this or do I need to remove them somehow first?

Thanks for all your help,
Robert
Re: Portage-related AVCs [ In reply to ]
On Wed, Nov 23, 2016 at 04:59:03PM +0000, Robert Sharp wrote:
>
> On 23/11/16 15:58, Jason Zaman wrote:
> > Either is fine, but im probably just gonna stabilize the 2.6 userspace
> > in a couple weeks so that one is likely easier. and setools4 is waaay
> > better than 3. The important point is that you dont want to have both
> > policy.29 and policy.30 around. Then you get weirdness like if you
> > downgrade a kernel or something random it'll load in the old policy
> > which probably doesnt work properly, so whichever you pick, make sure
> > you nuke the other one. and semodule -B will rebuild the whole policy
> > again and load it.
> OK - I will go with policy.30 and add the keywords etc. I did a couple
> of local policy changes that may not be needed so will they disappear in
> all of this or do I need to remove them somehow first?

If they are in the module store tho, then it should just work without
needing to reinsert. Ie, if its in /var/lib/selinux/strict/...
If you have local changes tho, I'd just rebuild them and semodule -i them
again just in case, it cant hurt.

-- Jason
Re: Portage-related AVCs [ In reply to ]
On 23/11/16 16:59, Robert Sharp wrote:
>
> On 23/11/16 15:58, Jason Zaman wrote:
>> Either is fine, but im probably just gonna stabilize the 2.6 userspace
>> in a couple weeks so that one is likely easier. and setools4 is waaay
>> better than 3. The important point is that you dont want to have both
>> policy.29 and policy.30 around. Then you get weirdness like if you
>> downgrade a kernel or something random it'll load in the old policy
>> which probably doesnt work properly, so whichever you pick, make sure
>> you nuke the other one. and semodule -B will rebuild the whole policy
>> again and load it.
> OK - I will go with policy.30 and add the keywords etc. I did a couple
> of local policy changes that may not be needed so will they disappear
> in all of this or do I need to remove them somehow first?
>
> Thanks for all your help,
> Robert
>
Sorry - noticed a couple of things while preping the emerge:

1) selinux-base-policy is blocking policycoreutils so presumably I need
to add that to my accept_keywords?
2) this package has the "unconfined" use flag set but I don't use
unconfined. Does that matter?

Thanks again,
Robert
Re: Portage-related AVCs [ In reply to ]
On Wed, Nov 23, 2016 at 05:20:59PM +0000, Robert Sharp wrote:
> On 23/11/16 16:59, Robert Sharp wrote:
> >
> > On 23/11/16 15:58, Jason Zaman wrote:
> >> Either is fine, but im probably just gonna stabilize the 2.6 userspace
> >> in a couple weeks so that one is likely easier. and setools4 is waaay
> >> better than 3. The important point is that you dont want to have both
> >> policy.29 and policy.30 around. Then you get weirdness like if you
> >> downgrade a kernel or something random it'll load in the old policy
> >> which probably doesnt work properly, so whichever you pick, make sure
> >> you nuke the other one. and semodule -B will rebuild the whole policy
> >> again and load it.
> > OK - I will go with policy.30 and add the keywords etc. I did a couple
> > of local policy changes that may not be needed so will they disappear
> > in all of this or do I need to remove them somehow first?
> >
> > Thanks for all your help,
> > Robert
> >
> Sorry - noticed a couple of things while preping the emerge:
>
> 1) selinux-base-policy is blocking policycoreutils so presumably I need
> to add that to my accept_keywords?
> 2) this package has the "unconfined" use flag set but I don't use
> unconfined. Does that matter?

Oh, yeah the 2.6 userland needs at minimum 2.20151208-r6. Its been long
enough, i'll stabilize the new policies right away so just wait a bit
any sync again.

unconfined useflag just builds it, if you are using strict you can turn
off unconfined and set this in make.conf:
POLICY_TYPES="strict"
then it wont even build the targetted modules at all.
Re: Portage-related AVCs [ In reply to ]
On 23/11/16 17:30, Jason Zaman wrote:
> On Wed, Nov 23, 2016 at 05:20:59PM +0000, Robert Sharp wrote:
>> On 23/11/16 16:59, Robert Sharp wrote:
>>> On 23/11/16 15:58, Jason Zaman wrote:
>>>> Either is fine, but im probably just gonna stabilize the 2.6 userspace
>>>> in a couple weeks so that one is likely easier. and setools4 is waaay
>>>> better than 3. The important point is that you dont want to have both
>>>> policy.29 and policy.30 around. Then you get weirdness like if you
>>>> downgrade a kernel or something random it'll load in the old policy
>>>> which probably doesnt work properly, so whichever you pick, make sure
>>>> you nuke the other one. and semodule -B will rebuild the whole policy
>>>> again and load it.
>>> OK - I will go with policy.30 and add the keywords etc. I did a couple
>>> of local policy changes that may not be needed so will they disappear
>>> in all of this or do I need to remove them somehow first?
>>>
>>> Thanks for all your help,
>>> Robert
>>>
>> Sorry - noticed a couple of things while preping the emerge:
>>
>> 1) selinux-base-policy is blocking policycoreutils so presumably I need
>> to add that to my accept_keywords?
>> 2) this package has the "unconfined" use flag set but I don't use
>> unconfined. Does that matter?
> Oh, yeah the 2.6 userland needs at minimum 2.20151208-r6. Its been long
> enough, i'll stabilize the new policies right away so just wait a bit
> any sync again.
>
> unconfined useflag just builds it, if you are using strict you can turn
> off unconfined and set this in make.conf:
> POLICY_TYPES="strict"
> then it wont even build the targetted modules at all.
>
Thanks Jason - you have been busy. I have just updated to 20151208-r6
and when I run semodule -B I get this message:

"libsemanage.add_user: user system_u not in password file"

Googling suggests this was a problem in Fedora (see bug
https://bugzilla.redhat.com/show_bug.cgi?id=1378204) and it was fixed a
few days ago in their selinux-policy-3.13.1-191.20.fc24. I ran sesearch
as before and it comes up with the same results as before so I assume
the semodule command did not do what it was supposed to do. Is there a
work around for this or should I go ~arch on the policy as well? If so,
is there a way to avoid listing all the policy packages in my
accept_keywords file?

Thanks again,
Robert
Re: Portage-related AVCs [ In reply to ]
On Thu, Nov 24, 2016 at 03:29:54PM +0000, Robert Sharp wrote:
> On 23/11/16 17:30, Jason Zaman wrote:
> > On Wed, Nov 23, 2016 at 05:20:59PM +0000, Robert Sharp wrote:
> >> On 23/11/16 16:59, Robert Sharp wrote:
> >>> On 23/11/16 15:58, Jason Zaman wrote:
> >>>> Either is fine, but im probably just gonna stabilize the 2.6 userspace
> >>>> in a couple weeks so that one is likely easier. and setools4 is waaay
> >>>> better than 3. The important point is that you dont want to have both
> >>>> policy.29 and policy.30 around. Then you get weirdness like if you
> >>>> downgrade a kernel or something random it'll load in the old policy
> >>>> which probably doesnt work properly, so whichever you pick, make sure
> >>>> you nuke the other one. and semodule -B will rebuild the whole policy
> >>>> again and load it.
> >>> OK - I will go with policy.30 and add the keywords etc. I did a couple
> >>> of local policy changes that may not be needed so will they disappear
> >>> in all of this or do I need to remove them somehow first?
> >>>
> >>> Thanks for all your help,
> >>> Robert
> >>>
> >> Sorry - noticed a couple of things while preping the emerge:
> >>
> >> 1) selinux-base-policy is blocking policycoreutils so presumably I need
> >> to add that to my accept_keywords?
> >> 2) this package has the "unconfined" use flag set but I don't use
> >> unconfined. Does that matter?
> > Oh, yeah the 2.6 userland needs at minimum 2.20151208-r6. Its been long
> > enough, i'll stabilize the new policies right away so just wait a bit
> > any sync again.
> >
> > unconfined useflag just builds it, if you are using strict you can turn
> > off unconfined and set this in make.conf:
> > POLICY_TYPES="strict"
> > then it wont even build the targetted modules at all.
> >
> Thanks Jason - you have been busy. I have just updated to 20151208-r6
> and when I run semodule -B I get this message:
>
> "libsemanage.add_user: user system_u not in password file"

That warning is harmless, i'll remove the line from the policy later.
for now ignore it or manually remove the line to silence the warning.
http://blog.perfinion.com/2016/10/selinux-userspace-26-released/

>
> Googling suggests this was a problem in Fedora (see bug
> https://bugzilla.redhat.com/show_bug.cgi?id=1378204) and it was fixed a
> few days ago in their selinux-policy-3.13.1-191.20.fc24. I ran sesearch
> as before and it comes up with the same results as before so I assume
> the semodule command did not do what it was supposed to do. Is there a
> work around for this or should I go ~arch on the policy as well? If so,
> is there a way to avoid listing all the policy packages in my
> accept_keywords file?
>
> Thanks again,
> Robert
>
Re: Portage-related AVCs [ In reply to ]
On 24/11/16 17:07, Jason Zaman wrote:
> That warning is harmless, i'll remove the line from the policy later.
> for now ignore it or manually remove the line to silence the warning.
> http://blog.perfinion.com/2016/10/selinux-userspace-26-released/

Sorry Jason, but I am not making much progress. I have emerged as you
suggested with the 20151208-r6 versions (and setools4). When I repeat
the search for portage_sandbox I get the same results as before:

# sesearch -s portage_sandbox_t -t portage_tmp_t -A
allow portage_sandbox_t non_auth_file_type:dir { search read lock
getattr ioctl open };
allow portage_sandbox_t non_auth_file_type:file { read lock ioctl open
getattr };
allow portage_sandbox_t non_auth_file_type:lnk_file { read getattr };
allow portage_sandbox_t portage_tmp_t:dir { rename search setattr read
lock create reparent getattr write ioctl link rmdir remove_name unlink
open add_name };
allow portage_sandbox_t portage_tmp_t:fifo_file { rename setattr read
lock create getattr write ioctl link unlink open append };
allow portage_sandbox_t portage_tmp_t:file { rename execute setattr read
lock create getattr execute_no_trans write relabelfrom ioctl link
relabelto unlink open append };
allow portage_sandbox_t portage_tmp_t:lnk_file { rename setattr read
lock create getattr write ioctl link unlink };
allow portage_sandbox_t portage_tmp_t:sock_file { rename setattr read
lock create getattr write ioctl link unlink open append };

There is still no relableto/from in the dir rule. I am not sure the
module rebuild worked. I tried the semodule -B again with -v and it all
happens rather quickly:

# semodule -B -v
Committing changes:
libsemanage.add_user: user system_u not in password file
Ok: transaction number 0.

Doesn't seem like it spent long rebuilding all those policies, but then
I wouldn't know if it is supposed to be quick?

Also, there doesn't seem to be a very easy way to confirm what policy
version is in place? I once saw a listing from semodule -l that included
version information but it doesn't happen on my system.

Robert
Re: Portage-related AVCs [ In reply to ]
On Thu, Nov 24, 2016 at 09:13:35PM +0000, Robert Sharp wrote:
> On 24/11/16 17:07, Jason Zaman wrote:
> > That warning is harmless, i'll remove the line from the policy later.
> > for now ignore it or manually remove the line to silence the warning.
> > http://blog.perfinion.com/2016/10/selinux-userspace-26-released/
>
> Sorry Jason, but I am not making much progress. I have emerged as you
> suggested with the 20151208-r6 versions (and setools4). When I repeat
> the search for portage_sandbox I get the same results as before:

OH! I just looked harder at my configs, I do have this locally on my
laptop:
allow portage_sandbox_t portage_tmp_t:dir { relabelfrom relabelto };
I hadnt added it to the policies yet tho. I forgot why I needed it :(.
Do all packages fail without it or only some?
I will add it to the next policy release, I guess it was my fault all
along :-P, sorry about that.

> # sesearch -s portage_sandbox_t -t portage_tmp_t -A
> allow portage_sandbox_t non_auth_file_type:dir { search read lock
> getattr ioctl open };
> allow portage_sandbox_t non_auth_file_type:file { read lock ioctl open
> getattr };
> allow portage_sandbox_t non_auth_file_type:lnk_file { read getattr };
> allow portage_sandbox_t portage_tmp_t:dir { rename search setattr read
> lock create reparent getattr write ioctl link rmdir remove_name unlink
> open add_name };
> allow portage_sandbox_t portage_tmp_t:fifo_file { rename setattr read
> lock create getattr write ioctl link unlink open append };
> allow portage_sandbox_t portage_tmp_t:file { rename execute setattr read
> lock create getattr execute_no_trans write relabelfrom ioctl link
> relabelto unlink open append };
> allow portage_sandbox_t portage_tmp_t:lnk_file { rename setattr read
> lock create getattr write ioctl link unlink };
> allow portage_sandbox_t portage_tmp_t:sock_file { rename setattr read
> lock create getattr write ioctl link unlink open append };
>
> There is still no relableto/from in the dir rule. I am not sure the
> module rebuild worked. I tried the semodule -B again with -v and it all
> happens rather quickly:
>
> # semodule -B -v
> Committing changes:
> libsemanage.add_user: user system_u not in password file
> Ok: transaction number 0.
>
> Doesn't seem like it spent long rebuilding all those policies, but then
> I wouldn't know if it is supposed to be quick?
>
> Also, there doesn't seem to be a very easy way to confirm what policy
> version is in place? I once saw a listing from semodule -l that included
> version information but it doesn't happen on my system.
The policy versions that semodule reports are what the policy_module
line in the source which was annoying to look up too. newer userspace is
based off CIL which doesnt have those version numbers at all anymore.

-- Jason
Re: Portage-related AVCs [ In reply to ]
On Thu, 24 Nov 2016 15:29:54 +0000
Robert Sharp <selinux@sharp.homelinux.org> wrote:

> [snip]
> If so, is there a way to avoid listing all the policy packages
> in my accept_keywords file?
>

Yes, there is. You can use globs in package.accepts_keywords; for
example "sec-policy/*"

Regards,
Luis