Strange AVC with latest rawhide kernel.

Strange AVC with latest rawhide kernel.

[Daniel J Walsh]

audit2allow -wla
type=AVC msg=audit(1456422969.279:1434): avc:  denied  { entrypoint }
for  pid=23847 comm="exe" path="/usr/bin/bash" dev="dm-2" ino=25165968
scontext=system_u:system_r:svirt_lxc_net_t:s0:c337,c895
tcontext=system_u:object_r:svirt_sandbox_file_t:s0:c337,c895
tclass=file permissive=0
	Was caused by:
		Unknown - would be allowed by active policy
		Possible mismatch between this policy and the one under
which the audit message was generated.

		Possible mismatch between current in-memory boolean
settings vs. permanent ones.

When trying to run a docker container on Rawhide, I am seeing this AVC.
The policy as audit2allow -w shows allows svirt_sandbox_file_t as an
entrypoint for svirt_lxc_net_t.

# sesearch -A -s svirt_lxc_net_t -t svirt_sandbox_file_t -c file -p
entrypoint
Found 1 semantic av rules:
   allow svirt_sandbox_domain file_type : file entrypoint ; 

But when I run try to start the container, docker blocks the access.  I
don't see any constraints that would block this, and don't think
NO_NEW_PRIV is enabled any way, and I don't think it would be involved
here. 

Any idea why SELinux is blocking the access?

Re: Strange AVC with latest rawhide kernel.

[Stephen Smalley]

On 02/25/2016 01:02 PM, Daniel J Walsh wrote:
> audit2allow -wla
> type=AVC msg=audit(1456422969.279:1434): avc:  denied  { entrypoint }
> for  pid=23847 comm="exe" path="/usr/bin/bash" dev="dm-2" ino=25165968
> scontext=system_u:system_r:svirt_lxc_net_t:s0:c337,c895
> tcontext=system_u:object_r:svirt_sandbox_file_t:s0:c337,c895
> tclass=file permissive=0
> 	Was caused by:
> 		Unknown - would be allowed by active policy
> 		Possible mismatch between this policy and the one under
> which the audit message was generated.
>
> 		Possible mismatch between current in-memory boolean
> settings vs. permanent ones.
>
> When trying to run a docker container on Rawhide, I am seeing this AVC.
> The policy as audit2allow -w shows allows svirt_sandbox_file_t as an
> entrypoint for svirt_lxc_net_t.
>
> # sesearch -A -s svirt_lxc_net_t -t svirt_sandbox_file_t -c file -p
> entrypoint
> Found 1 semantic av rules:
>     allow svirt_sandbox_domain file_type : file entrypoint ;
>
> But when I run try to start the container, docker blocks the access.  I
> don't see any constraints that would block this, and don't think
> NO_NEW_PRIV is enabled any way, and I don't think it would be involved
> here.
>
> Any idea why SELinux is blocking the access?

kernel version?

Re: Strange AVC with latest rawhide kernel.

[Stephen Smalley]

On 02/25/2016 01:02 PM, Daniel J Walsh wrote:
> audit2allow -wla
> type=AVC msg=audit(1456422969.279:1434): avc:  denied  { entrypoint }
> for  pid=23847 comm="exe" path="/usr/bin/bash" dev="dm-2" ino=25165968
> scontext=system_u:system_r:svirt_lxc_net_t:s0:c337,c895
> tcontext=system_u:object_r:svirt_sandbox_file_t:s0:c337,c895
> tclass=file permissive=0
> 	Was caused by:
> 		Unknown - would be allowed by active policy
> 		Possible mismatch between this policy and the one under
> which the audit message was generated.
>
> 		Possible mismatch between current in-memory boolean
> settings vs. permanent ones.
>
> When trying to run a docker container on Rawhide, I am seeing this AVC.
> The policy as audit2allow -w shows allows svirt_sandbox_file_t as an
> entrypoint for svirt_lxc_net_t.
>
> # sesearch -A -s svirt_lxc_net_t -t svirt_sandbox_file_t -c file -p
> entrypoint
> Found 1 semantic av rules:
>     allow svirt_sandbox_domain file_type : file entrypoint ;
>
> But when I run try to start the container, docker blocks the access.  I
> don't see any constraints that would block this, and don't think
> NO_NEW_PRIV is enabled any way, and I don't think it would be involved
> here.
>
> Any idea why SELinux is blocking the access?

Also, what does compute_av report for that (scontext, tcontext, tclass) 
triple?

Re: Strange AVC with latest rawhide kernel.

[Daniel J Walsh]

On Thu, 2016-02-25 at 13:18 -0500, Stephen Smalley wrote:
> On 02/25/2016 01:02 PM, Daniel J Walsh wrote:
> > 
> > audit2allow -wla
> > type=AVC msg=audit(1456422969.279:1434): avc:  denied  { entrypoint
> > }
> > for  pid=23847 comm="exe" path="/usr/bin/bash" dev="dm-2"
> > ino=25165968
> > scontext=system_u:system_r:svirt_lxc_net_t:s0:c337,c895
> > tcontext=system_u:object_r:svirt_sandbox_file_t:s0:c337,c895
> > tclass=file permissive=0
> > 	Was caused by:
> > 		Unknown - would be allowed by active policy
> > 		Possible mismatch between this policy and the one under
> > which the audit message was generated.
> > 
> > 		Possible mismatch between current in-memory boolean
> > settings vs. permanent ones.
> > 
> > When trying to run a docker container on Rawhide, I am seeing this
> > AVC.
> > The policy as audit2allow -w shows allows svirt_sandbox_file_t as
> > an
> > entrypoint for svirt_lxc_net_t.
> > 
> > # sesearch -A -s svirt_lxc_net_t -t svirt_sandbox_file_t -c file -p
> > entrypoint
> > Found 1 semantic av rules:
> >     allow svirt_sandbox_domain file_type : file entrypoint ;
> > 
> > But when I run try to start the container, docker blocks the
> > access.  I
> > don't see any constraints that would block this, and don't think
> > NO_NEW_PRIV is enabled any way, and I don't think it would be
> > involved
> > here.
> > 
> > Any idea why SELinux is blocking the access?
> Also, what does compute_av report for that (scontext, tcontext,
> tclass) 
> triple?
> 
> 

uname -r
4.5.0-0.rc5.git0.1.fc24.x86_64

./compute_av system_u:system_r:svirt_lxc_net_t:s0:c337,c895
system_u:object_r:svirt_sandbox_file_t:s0:c337,c895 file
allowed= { ioctl read write create getattr setattr lock relabelfrom
relabelto append unlink link rename execute execute_no_trans execmod
open }
auditdeny { ioctl read write create setattr lock relabelfrom relabelto
append unlink link rename execute swapon quotaon mounton
execute_no_trans entrypoint execmod open audit_access 0xffc00000 }

Looks like it is auditdeny, but I have no idea why.

Re: Strange AVC with latest rawhide kernel.

[Stephen Smalley]

On 02/25/2016 01:59 PM, Daniel J Walsh wrote:
> On Thu, 2016-02-25 at 13:18 -0500, Stephen Smalley wrote:
>> On 02/25/2016 01:02 PM, Daniel J Walsh wrote:
>>>
>>> audit2allow -wla
>>> type=AVC msg=audit(1456422969.279:1434): avc:  denied  { entrypoint
>>> }
>>> for  pid=23847 comm="exe" path="/usr/bin/bash" dev="dm-2"
>>> ino=25165968
>>> scontext=system_u:system_r:svirt_lxc_net_t:s0:c337,c895
>>> tcontext=system_u:object_r:svirt_sandbox_file_t:s0:c337,c895
>>> tclass=file permissive=0
>>> 	Was caused by:
>>> 		Unknown - would be allowed by active policy
>>> 		Possible mismatch between this policy and the one under
>>> which the audit message was generated.
>>>
>>> 		Possible mismatch between current in-memory boolean
>>> settings vs. permanent ones.
>>>
>>> When trying to run a docker container on Rawhide, I am seeing this
>>> AVC.
>>> The policy as audit2allow -w shows allows svirt_sandbox_file_t as
>>> an
>>> entrypoint for svirt_lxc_net_t.
>>>
>>> # sesearch -A -s svirt_lxc_net_t -t svirt_sandbox_file_t -c file -p
>>> entrypoint
>>> Found 1 semantic av rules:
>>>      allow svirt_sandbox_domain file_type : file entrypoint ;
>>>
>>> But when I run try to start the container, docker blocks the
>>> access.  I
>>> don't see any constraints that would block this, and don't think
>>> NO_NEW_PRIV is enabled any way, and I don't think it would be
>>> involved
>>> here.
>>>
>>> Any idea why SELinux is blocking the access?
>> Also, what does compute_av report for that (scontext, tcontext,
>> tclass)
>> triple?
>>
>>
>
> uname -r
> 4.5.0-0.rc5.git0.1.fc24.x86_64
>
> ./compute_av system_u:system_r:svirt_lxc_net_t:s0:c337,c895
> system_u:object_r:svirt_sandbox_file_t:s0:c337,c895 file
> allowed= { ioctl read write create getattr setattr lock relabelfrom
> relabelto append unlink link rename execute execute_no_trans execmod
> open }
> auditdeny { ioctl read write create setattr lock relabelfrom relabelto
> append unlink link rename execute swapon quotaon mounton
> execute_no_trans entrypoint execmod open audit_access 0xffc00000 }
>
> Looks like it is auditdeny, but I have no idea why.

No, auditdeny is fine (default is to audit all denials, so all-bits-set, 
even for undefined permissions).  The question is why isn't entrypoint 
listed in allowed - that shows that your kernel is indeed saying that 
entrypoint isn't allowed.

Running the same kernel, with selinux-policy-3.13.1.171.fc24, when I run 
the same compute_av command as above, entrypoint is listed in allowed 
(in between execute_no_trans and execmod).  Your policy is what?

Re: Strange AVC with latest rawhide kernel.

[Daniel J Walsh]

On Thu, 2016-02-25 at 14:12 -0500, Stephen Smalley wrote:
> On 02/25/2016 01:59 PM, Daniel J Walsh wrote:
> > 
> > On Thu, 2016-02-25 at 13:18 -0500, Stephen Smalley wrote:
> > > 
> > > On 02/25/2016 01:02 PM, Daniel J Walsh wrote:
> > > > 
> > > > 
> > > > audit2allow -wla
> > > > type=AVC msg=audit(1456422969.279:1434): avc:  denied  {
> > > > entrypoint
> > > > }
> > > > for  pid=23847 comm="exe" path="/usr/bin/bash" dev="dm-2"
> > > > ino=25165968
> > > > scontext=system_u:system_r:svirt_lxc_net_t:s0:c337,c895
> > > > tcontext=system_u:object_r:svirt_sandbox_file_t:s0:c337,c895
> > > > tclass=file permissive=0
> > > > 	Was caused by:
> > > > 		Unknown - would be allowed by active policy
> > > > 		Possible mismatch between this policy and the
> > > > one under
> > > > which the audit message was generated.
> > > > 
> > > > 		Possible mismatch between current in-memory
> > > > boolean
> > > > settings vs. permanent ones.
> > > > 
> > > > When trying to run a docker container on Rawhide, I am seeing
> > > > this
> > > > AVC.
> > > > The policy as audit2allow -w shows allows svirt_sandbox_file_t
> > > > as
> > > > an
> > > > entrypoint for svirt_lxc_net_t.
> > > > 
> > > > # sesearch -A -s svirt_lxc_net_t -t svirt_sandbox_file_t -c
> > > > file -p
> > > > entrypoint
> > > > Found 1 semantic av rules:
> > > >      allow svirt_sandbox_domain file_type : file entrypoint ;
> > > > 
> > > > But when I run try to start the container, docker blocks the
> > > > access.  I
> > > > don't see any constraints that would block this, and don't
> > > > think
> > > > NO_NEW_PRIV is enabled any way, and I don't think it would be
> > > > involved
> > > > here.
> > > > 
> > > > Any idea why SELinux is blocking the access?
> > > Also, what does compute_av report for that (scontext, tcontext,
> > > tclass)
> > > triple?
> > > 
> > > 
> > uname -r
> > 4.5.0-0.rc5.git0.1.fc24.x86_64
> > 
> > ./compute_av system_u:system_r:svirt_lxc_net_t:s0:c337,c895
> > system_u:object_r:svirt_sandbox_file_t:s0:c337,c895 file
> > allowed= { ioctl read write create getattr setattr lock relabelfrom
> > relabelto append unlink link rename execute execute_no_trans
> > execmod
> > open }
> > auditdeny { ioctl read write create setattr lock relabelfrom
> > relabelto
> > append unlink link rename execute swapon quotaon mounton
> > execute_no_trans entrypoint execmod open audit_access 0xffc00000 }
> > 
> > Looks like it is auditdeny, but I have no idea why.
> No, auditdeny is fine (default is to audit all denials, so all-bits-
> set, 
> even for undefined permissions).  The question is why isn't
> entrypoint 
> listed in allowed - that shows that your kernel is indeed saying
> that 
> entrypoint isn't allowed.
> 
> Running the same kernel, with selinux-policy-3.13.1.171.fc24, when I
> run 
> the same compute_av command as above, entrypoint is listed in
> allowed 
> (in between execute_no_trans and execmod).  Your policy is what?
> 
> 

rpm -q selinux-policy
selinux-policy-3.13.1-171.fc24.noarch

Ok I rm -rf /var/lib/selinux
dnf -y reinstall selinux-policy selinux-policy-targeted docker-selinux

And everything is working again.  

I have no idea what was going on, but maybe their was something screwed
up somewhere and I was loading a different policy then I was examining.

Re: Strange AVC with latest rawhide kernel.

[Eric Paris]

You added a type bounds right before this broke...  Does the parent
type have entrypoint? If not, maybe that's where it got stripped...

-Eric

On Thu, 2016-02-25 at 14:12 -0500, Stephen Smalley wrote:
> On 02/25/2016 01:59 PM, Daniel J Walsh wrote:
> > 
> > On Thu, 2016-02-25 at 13:18 -0500, Stephen Smalley wrote:
> > > 
> > > On 02/25/2016 01:02 PM, Daniel J Walsh wrote:
> > > > 
> > > > 
> > > > audit2allow -wla
> > > > type=AVC msg=audit(1456422969.279:1434): avc:  denied  {
> > > > entrypoint
> > > > }
> > > > for  pid=23847 comm="exe" path="/usr/bin/bash" dev="dm-2"
> > > > ino=25165968
> > > > scontext=system_u:system_r:svirt_lxc_net_t:s0:c337,c895
> > > > tcontext=system_u:object_r:svirt_sandbox_file_t:s0:c337,c895
> > > > tclass=file permissive=0
> > > > 	Was caused by:
> > > > 		Unknown - would be allowed by active policy
> > > > 		Possible mismatch between this policy and the
> > > > one under
> > > > which the audit message was generated.
> > > > 
> > > > 		Possible mismatch between current in-memory
> > > > boolean
> > > > settings vs. permanent ones.
> > > > 
> > > > When trying to run a docker container on Rawhide, I am seeing
> > > > this
> > > > AVC.
> > > > The policy as audit2allow -w shows allows svirt_sandbox_file_t
> > > > as
> > > > an
> > > > entrypoint for svirt_lxc_net_t.
> > > > 
> > > > # sesearch -A -s svirt_lxc_net_t -t svirt_sandbox_file_t -c
> > > > file -p
> > > > entrypoint
> > > > Found 1 semantic av rules:
> > > >      allow svirt_sandbox_domain file_type : file entrypoint ;
> > > > 
> > > > But when I run try to start the container, docker blocks the
> > > > access.  I
> > > > don't see any constraints that would block this, and don't
> > > > think
> > > > NO_NEW_PRIV is enabled any way, and I don't think it would be
> > > > involved
> > > > here.
> > > > 
> > > > Any idea why SELinux is blocking the access?
> > > Also, what does compute_av report for that (scontext, tcontext,
> > > tclass)
> > > triple?
> > > 
> > > 
> > uname -r
> > 4.5.0-0.rc5.git0.1.fc24.x86_64
> > 
> > ./compute_av system_u:system_r:svirt_lxc_net_t:s0:c337,c895
> > system_u:object_r:svirt_sandbox_file_t:s0:c337,c895 file
> > allowed= { ioctl read write create getattr setattr lock relabelfrom
> > relabelto append unlink link rename execute execute_no_trans
> > execmod
> > open }
> > auditdeny { ioctl read write create setattr lock relabelfrom
> > relabelto
> > append unlink link rename execute swapon quotaon mounton
> > execute_no_trans entrypoint execmod open audit_access 0xffc00000 }
> > 
> > Looks like it is auditdeny, but I have no idea why.
> No, auditdeny is fine (default is to audit all denials, so all-bits-
> set, 
> even for undefined permissions).  The question is why isn't
> entrypoint 
> listed in allowed - that shows that your kernel is indeed saying
> that 
> entrypoint isn't allowed.
> 
> Running the same kernel, with selinux-policy-3.13.1.171.fc24, when I
> run 
> the same compute_av command as above, entrypoint is listed in
> allowed 
> (in between execute_no_trans and execmod).  Your policy is what?
> 
> 

Re: Strange AVC with latest rawhide kernel.

[Stephen Smalley]

On 02/25/2016 02:37 PM, Eric Paris wrote:
> You added a type bounds right before this broke...  Does the parent
> type have entrypoint? If not, maybe that's where it got stripped...

That would match the behavior he described (although he should get an 
audit message of the form op=security_compute_av reason=bounds.. in 
audit.log or dmesg in that case).  The kernel automatically reduces 
permissions as required by typebounds.  The corresponding logic never 
made its way into the libsepol compute_av code, so audit2why wouldn't 
know about it, and sesearch merely searches for TE rules; it doesn't do 
anything about typebounds.  We should probably update libsepol 
compute_av (for that, and eventually for xperms).

>
> -Eric
>
> On Thu, 2016-02-25 at 14:12 -0500, Stephen Smalley wrote:
>> On 02/25/2016 01:59 PM, Daniel J Walsh wrote:
>>>
>>> On Thu, 2016-02-25 at 13:18 -0500, Stephen Smalley wrote:
>>>>
>>>> On 02/25/2016 01:02 PM, Daniel J Walsh wrote:
>>>>>
>>>>>
>>>>> audit2allow -wla
>>>>> type=AVC msg=audit(1456422969.279:1434): avc:  denied  {
>>>>> entrypoint
>>>>> }
>>>>> for  pid=23847 comm="exe" path="/usr/bin/bash" dev="dm-2"
>>>>> ino=25165968
>>>>> scontext=system_u:system_r:svirt_lxc_net_t:s0:c337,c895
>>>>> tcontext=system_u:object_r:svirt_sandbox_file_t:s0:c337,c895
>>>>> tclass=file permissive=0
>>>>> 	Was caused by:
>>>>> 		Unknown - would be allowed by active policy
>>>>> 		Possible mismatch between this policy and the
>>>>> one under
>>>>> which the audit message was generated.
>>>>>
>>>>> 		Possible mismatch between current in-memory
>>>>> boolean
>>>>> settings vs. permanent ones.
>>>>>
>>>>> When trying to run a docker container on Rawhide, I am seeing
>>>>> this
>>>>> AVC.
>>>>> The policy as audit2allow -w shows allows svirt_sandbox_file_t
>>>>> as
>>>>> an
>>>>> entrypoint for svirt_lxc_net_t.
>>>>>
>>>>> # sesearch -A -s svirt_lxc_net_t -t svirt_sandbox_file_t -c
>>>>> file -p
>>>>> entrypoint
>>>>> Found 1 semantic av rules:
>>>>>       allow svirt_sandbox_domain file_type : file entrypoint ;
>>>>>
>>>>> But when I run try to start the container, docker blocks the
>>>>> access.  I
>>>>> don't see any constraints that would block this, and don't
>>>>> think
>>>>> NO_NEW_PRIV is enabled any way, and I don't think it would be
>>>>> involved
>>>>> here.
>>>>>
>>>>> Any idea why SELinux is blocking the access?
>>>> Also, what does compute_av report for that (scontext, tcontext,
>>>> tclass)
>>>> triple?
>>>>
>>>>
>>> uname -r
>>> 4.5.0-0.rc5.git0.1.fc24.x86_64
>>>
>>> ./compute_av system_u:system_r:svirt_lxc_net_t:s0:c337,c895
>>> system_u:object_r:svirt_sandbox_file_t:s0:c337,c895 file
>>> allowed= { ioctl read write create getattr setattr lock relabelfrom
>>> relabelto append unlink link rename execute execute_no_trans
>>> execmod
>>> open }
>>> auditdeny { ioctl read write create setattr lock relabelfrom
>>> relabelto
>>> append unlink link rename execute swapon quotaon mounton
>>> execute_no_trans entrypoint execmod open audit_access 0xffc00000 }
>>>
>>> Looks like it is auditdeny, but I have no idea why.
>> No, auditdeny is fine (default is to audit all denials, so all-bits-
>> set,
>> even for undefined permissions).  The question is why isn't
>> entrypoint
>> listed in allowed - that shows that your kernel is indeed saying
>> that
>> entrypoint isn't allowed.
>>
>> Running the same kernel, with selinux-policy-3.13.1.171.fc24, when I
>> run
>> the same compute_av command as above, entrypoint is listed in
>> allowed
>> (in between execute_no_trans and execmod).  Your policy is what?
>>
>>
>

Re: Strange AVC with latest rawhide kernel.

[Daniel J Walsh]

On Thu, 2016-02-25 at 14:47 -0500, Stephen Smalley wrote:
> On 02/25/2016 02:37 PM, Eric Paris wrote:
> > 
> > You added a type bounds right before this broke...  Does the parent
> > type have entrypoint? If not, maybe that's where it got stripped...
> That would match the behavior he described (although he should get
> an 
> audit message of the form op=security_compute_av reason=bounds.. in 
> audit.log or dmesg in that case).  The kernel automatically reduces 
> permissions as required by typebounds.  The corresponding logic
> never 
> made its way into the libsepol compute_av code, so audit2why
> wouldn't 
> know about it, and sesearch merely searches for TE rules; it doesn't
> do 
> anything about typebounds.  We should probably update libsepol 
> compute_av (for that, and eventually for xperms).
> 

That would make sense, and then when I blew it away everything works
again.  

So if I do a typebounds on docker_t svirt_lxc_net_t, I have to make
sure docker_t can use svirt_sandbox_file_t as an entrypoint?

BTW we have a problem with type bounds, which only allows one.  We
would like to be able to say

typebounds unconfined_t svirt_lxc_net_t;
typebounds docker_t svirt_lxc_net_t;

This would allow runc and docker to transition to svirt_lxc_net_t, if
the user specified prctl(NO_NEW_PRIVS)

Currently typebounds only allows one instance.

Re: Strange AVC with latest rawhide kernel.

[Stephen Smalley]

On 02/25/2016 03:28 PM, Daniel J Walsh wrote:
> On Thu, 2016-02-25 at 14:47 -0500, Stephen Smalley wrote:
>> On 02/25/2016 02:37 PM, Eric Paris wrote:
>>>
>>> You added a type bounds right before this broke...  Does the parent
>>> type have entrypoint? If not, maybe that's where it got stripped...
>> That would match the behavior he described (although he should get
>> an
>> audit message of the form op=security_compute_av reason=bounds.. in
>> audit.log or dmesg in that case).  The kernel automatically reduces
>> permissions as required by typebounds.  The corresponding logic
>> never
>> made its way into the libsepol compute_av code, so audit2why
>> wouldn't
>> know about it, and sesearch merely searches for TE rules; it doesn't
>> do
>> anything about typebounds.  We should probably update libsepol
>> compute_av (for that, and eventually for xperms).
>>
>
> That would make sense, and then when I blew it away everything works
> again.
>
> So if I do a typebounds on docker_t svirt_lxc_net_t, I have to make
> sure docker_t can use svirt_sandbox_file_t as an entrypoint?

As currently defined/implemented, yes - a bounded type cannot be allowed 
anything that is not allowed to its parent.  If you had 
neverallow/hierarchy checking enabled in your policy build (e.g. 
expand-check=1 or manual semodule_expand test), then it would have 
triggered at link time.  Otherwise the kernel prunes it for you.

>
> BTW we have a problem with type bounds, which only allows one.  We
> would like to be able to say
>
> typebounds unconfined_t svirt_lxc_net_t;
> typebounds docker_t svirt_lxc_net_t;
>
> This would allow runc and docker to transition to svirt_lxc_net_t, if
> the user specified prctl(NO_NEW_PRIVS)
>
> Currently typebounds only allows one instance.

It is a hierarchy, where each child has a single parent.  So you can 
define hierarchies like:
typebounds unconfined_t docker_t;
typebounds docker_t svirt_lxc_net_t;
and then they can both transition because they are both ancestors.

Re: Strange AVC with latest rawhide kernel.

[Daniel J Walsh]

On Thu, 2016-02-25 at 15:54 -0500, Stephen Smalley wrote:
> On 02/25/2016 03:28 PM, Daniel J Walsh wrote:
> > 
> > On Thu, 2016-02-25 at 14:47 -0500, Stephen Smalley wrote:
> > > 
> > > On 02/25/2016 02:37 PM, Eric Paris wrote:
> > > > 
> > > > 
> > > > You added a type bounds right before this broke...  Does the
> > > > parent
> > > > type have entrypoint? If not, maybe that's where it got
> > > > stripped...
> > > That would match the behavior he described (although he should
> > > get
> > > an
> > > audit message of the form op=security_compute_av reason=bounds..
> > > in
> > > audit.log or dmesg in that case).  The kernel automatically
> > > reduces
> > > permissions as required by typebounds.  The corresponding logic
> > > never
> > > made its way into the libsepol compute_av code, so audit2why
> > > wouldn't
> > > know about it, and sesearch merely searches for TE rules; it
> > > doesn't
> > > do
> > > anything about typebounds.  We should probably update libsepol
> > > compute_av (for that, and eventually for xperms).
> > > 
> > That would make sense, and then when I blew it away everything
> > works
> > again.
> > 
> > So if I do a typebounds on docker_t svirt_lxc_net_t, I have to make
> > sure docker_t can use svirt_sandbox_file_t as an entrypoint?
> As currently defined/implemented, yes - a bounded type cannot be
> allowed 
> anything that is not allowed to its parent.  If you had 
> neverallow/hierarchy checking enabled in your policy build (e.g. 
> expand-check=1 or manual semodule_expand test), then it would have 
> triggered at link time.  Otherwise the kernel prunes it for you.
> 
> > 
> > 
> > BTW we have a problem with type bounds, which only allows one.  We
> > would like to be able to say
> > 
> > typebounds unconfined_t svirt_lxc_net_t;
> > typebounds docker_t svirt_lxc_net_t;
> > 
> > This would allow runc and docker to transition to svirt_lxc_net_t,
> > if
> > the user specified prctl(NO_NEW_PRIVS)
> > 
> > Currently typebounds only allows one instance.
> It is a hierarchy, where each child has a single parent.  So you can 
> define hierarchies like:
> typebounds unconfined_t docker_t;
> typebounds docker_t svirt_lxc_net_t;
> and then they can both transition because they are both ancestors.
> 
> 

Awesome idea.

Re: Strange AVC with latest rawhide kernel.

[Paul Moore]

On Fri, Feb 26, 2016 at 7:54 AM, Daniel J Walsh <dwalsh@redhat.com> wrote:
> On Thu, 2016-02-25 at 15:54 -0500, Stephen Smalley wrote:
>> On 02/25/2016 03:28 PM, Daniel J Walsh wrote:
>> > Currently typebounds only allows one instance.
>> It is a hierarchy, where each child has a single parent.  So you can
>> define hierarchies like:
>> typebounds unconfined_t docker_t;
>> typebounds docker_t svirt_lxc_net_t;
>> and then they can both transition because they are both ancestors.
>
> Awesome idea.

Would that resolve all your problems Dan with Docker, runc, etc.?
>From our discussions the other day I thought you needed the ability to
transition to svirt_lxc_net_t from domains other than unconfined_t and
docker_t ... or was I misunderstanding you?

-- 
paul moore
www.paul-moore.com

Re: Strange AVC with latest rawhide kernel.

[Stephen Smalley]

On 02/26/2016 10:46 AM, Paul Moore wrote:
> On Fri, Feb 26, 2016 at 7:54 AM, Daniel J Walsh <dwalsh@redhat.com> wrote:
>> On Thu, 2016-02-25 at 15:54 -0500, Stephen Smalley wrote:
>>> On 02/25/2016 03:28 PM, Daniel J Walsh wrote:
>>>> Currently typebounds only allows one instance.
>>> It is a hierarchy, where each child has a single parent.  So you can
>>> define hierarchies like:
>>> typebounds unconfined_t docker_t;
>>> typebounds docker_t svirt_lxc_net_t;
>>> and then they can both transition because they are both ancestors.
>>
>> Awesome idea.
>
> Would that resolve all your problems Dan with Docker, runc, etc.?
>>From our discussions the other day I thought you needed the ability to
> transition to svirt_lxc_net_t from domains other than unconfined_t and
> docker_t ... or was I misunderstanding you?
>

Note that it is only exec-based transitions that are affected by 
NO_NEW_PRIVS, so one can always leverage dynamic transitions (i.e. 
setcon) without requiring typebounds.

Re: Strange AVC with latest rawhide kernel.

[Daniel J Walsh]

On Fri, 2016-02-26 at 10:49 -0500, Stephen Smalley wrote:
> On 02/26/2016 10:46 AM, Paul Moore wrote:
> > 
> > On Fri, Feb 26, 2016 at 7:54 AM, Daniel J Walsh <dwalsh@redhat.com>
> > wrote:
> > > 
> > > On Thu, 2016-02-25 at 15:54 -0500, Stephen Smalley wrote:
> > > > 
> > > > On 02/25/2016 03:28 PM, Daniel J Walsh wrote:
> > > > > 
> > > > > Currently typebounds only allows one instance.
> > > > It is a hierarchy, where each child has a single parent.  So
> > > > you can
> > > > define hierarchies like:
> > > > typebounds unconfined_t docker_t;
> > > > typebounds docker_t svirt_lxc_net_t;
> > > > and then they can both transition because they are both
> > > > ancestors.
> > > Awesome idea.
> > Would that resolve all your problems Dan with Docker, runc, etc.?
> > > 
> > > From our discussions the other day I thought you needed the
> > > ability to
> > transition to svirt_lxc_net_t from domains other than unconfined_t
> > and
> > docker_t ... or was I misunderstanding you?
> > 
> Note that it is only exec-based transitions that are affected by 
> NO_NEW_PRIVS, so one can always leverage dynamic transitions (i.e. 
> setcon) without requiring typebounds.
> 
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho
> .nsa.gov.
> 
> 

BTW I turned on the expand-check=1 in semanage.conf and semodule -B
went nuts and crashed.

On this policy.

policy_module(mypol, 1.0)

require {
	type svirt_lxc_net_t;
	type docker_t;
	type svirt_sandbox_file_t;
	type unconfined_t;
}
allow unconfined_t svirt_sandbox_file_t:file entrypoint;
allow docker_t svirt_sandbox_file_t:file entrypoint;
typebounds unconfined_t docker_t;
typebounds docker_t svirt_lxc_net_t;

Re: Strange AVC with latest rawhide kernel.

[James Carter]

On 02/26/2016 11:33 AM, Daniel J Walsh wrote:
>
> BTW I turned on the expand-check=1 in semanage.conf and semodule -B
> went nuts and crashed.
>
> On this policy.
>
> policy_module(mypol, 1.0)
>
> require {
> 	type svirt_lxc_net_t;
> 	type docker_t;
> 	type svirt_sandbox_file_t;
> 	type unconfined_t;
> }
> allow unconfined_t svirt_sandbox_file_t:file entrypoint;
> allow docker_t svirt_sandbox_file_t:file entrypoint;
> typebounds unconfined_t docker_t;
> typebounds docker_t svirt_lxc_net_t;
>
>

I thought that maybe the toolchain couldn't handle an A bounds B bounds C 
relationship, but current versions handle that just fine and even versions back 
in June before I refactored the bounds checking could handle it. I only checked 
with checkpolicy and secilc, so there is a chance that something particular with 
modules caused this.

I tried your module on Fedora 23 and the first bounds check fails. Nothing crazy 
happened though. I don't currently have a rawhide machine to try it on.

-- 
James Carter <jwcart2@tycho.nsa.gov>
National Security Agency

Re: Strange AVC with latest rawhide kernel.

[Daniel J Walsh]

[-- Attachment #1: Type: text/plain, Size: 1336 bytes --]

On Fri, 2016-02-26 at 14:50 -0500, James Carter wrote:
> On 02/26/2016 11:33 AM, Daniel J Walsh wrote:
> >
> >
> > BTW I turned on the expand-check=1 in semanage.conf and semodule -B
> > went nuts and crashed.
> >
> > On this policy.
> >
> > policy_module(mypol, 1.0)
> >
> > require {
> > 	type svirt_lxc_net_t;
> > 	type docker_t;
> > 	type svirt_sandbox_file_t;
> > 	type unconfined_t;
> > }
> > allow unconfined_t svirt_sandbox_file_t:file entrypoint;
> > allow docker_t svirt_sandbox_file_t:file entrypoint;
> > typebounds unconfined_t docker_t;
> > typebounds docker_t svirt_lxc_net_t;
> >
> >
> I thought that maybe the toolchain couldn't handle an A bounds B
> bounds C 
> relationship, but current versions handle that just fine and even
> versions back 
> in June before I refactored the bounds checking could handle it. I
> only checked 
> with checkpolicy and secilc, so there is a chance that something
> particular with 
> modules caused this.
>
> I tried your module on Fedora 23 and the first bounds check fails.
> Nothing crazy 
> happened though. I don't currently have a rawhide machine to try it
> on.
>

I guess unconfined_t also needs docker_exec_t as an entrypoint.

Still crashes.  Here is the output and strace.
# strace -o /tmp/strace semodule -B 2> /tmp/out


[-- Attachment #2: strace.gz --]
[-- Type: application/gzip, Size: 223874 bytes --]

[-- Attachment #3: out.gz --]
[-- Type: application/gzip, Size: 12328 bytes --]

Re: Strange AVC with latest rawhide kernel.

[James Carter]

On 02/26/2016 03:30 PM, Daniel J Walsh wrote:
> On Fri, 2016-02-26 at 14:50 -0500, James Carter wrote:
>> On 02/26/2016 11:33 AM, Daniel J Walsh wrote:
>>>
>>>
>>> BTW I turned on the expand-check=1 in semanage.conf and semodule -B
>>> went nuts and crashed.
>>>
>>> On this policy.
>>>
>>> policy_module(mypol, 1.0)
>>>
>>> require {
>>> 	type svirt_lxc_net_t;
>>> 	type docker_t;
>>> 	type svirt_sandbox_file_t;
>>> 	type unconfined_t;
>>> }
>>> allow unconfined_t svirt_sandbox_file_t:file entrypoint;
>>> allow docker_t svirt_sandbox_file_t:file entrypoint;
>>> typebounds unconfined_t docker_t;
>>> typebounds docker_t svirt_lxc_net_t;
>>>
>>>
>> I thought that maybe the toolchain couldn't handle an A bounds B
>> bounds C
>> relationship, but current versions handle that just fine and even
>> versions back
>> in June before I refactored the bounds checking could handle it. I
>> only checked
>> with checkpolicy and secilc, so there is a chance that something
>> particular with
>> modules caused this.
>>
>> I tried your module on Fedora 23 and the first bounds check fails.
>> Nothing crazy
>> happened though. I don't currently have a rawhide machine to try it
>> on.
>>
>
> I guess unconfined_t also needs docker_exec_t as an entrypoint.
>
> Still crashes.  Here is the output and strace.
> # strace -o /tmp/strace semodule -B 2> /tmp/out
>

Is your policy available somewhere, so I can try to reproduce this?

Jim


-- 
James Carter <jwcart2@tycho.nsa.gov>
National Security Agency

Re: Strange AVC with latest rawhide kernel.

[Daniel J Walsh]

On 02/29/2016 11:27 AM, James Carter wrote:
> On 02/26/2016 03:30 PM, Daniel J Walsh wrote:
>> On Fri, 2016-02-26 at 14:50 -0500, James Carter wrote:
>>> On 02/26/2016 11:33 AM, Daniel J Walsh wrote:
>>>>
>>>>
>>>> BTW I turned on the expand-check=1 in semanage.conf and semodule -B
>>>> went nuts and crashed.
>>>>
>>>> On this policy.
>>>>
>>>> policy_module(mypol, 1.0)
>>>>
>>>> require {
>>>>     type svirt_lxc_net_t;
>>>>     type docker_t;
>>>>     type svirt_sandbox_file_t;
>>>>     type unconfined_t;
>>>> }
>>>> allow unconfined_t svirt_sandbox_file_t:file entrypoint;
>>>> allow docker_t svirt_sandbox_file_t:file entrypoint;
>>>> typebounds unconfined_t docker_t;
>>>> typebounds docker_t svirt_lxc_net_t;
>>>>
>>>>
>>> I thought that maybe the toolchain couldn't handle an A bounds B
>>> bounds C
>>> relationship, but current versions handle that just fine and even
>>> versions back
>>> in June before I refactored the bounds checking could handle it. I
>>> only checked
>>> with checkpolicy and secilc, so there is a chance that something
>>> particular with
>>> modules caused this.
>>>
>>> I tried your module on Fedora 23 and the first bounds check fails.
>>> Nothing crazy
>>> happened though. I don't currently have a rawhide machine to try it
>>> on.
>>>
>>
>> I guess unconfined_t also needs docker_exec_t as an entrypoint.
>>
>> Still crashes.  Here is the output and strace.
>> # strace -o /tmp/strace semodule -B 2> /tmp/out
>>
>
> Is your policy available somewhere, so I can try to reproduce this?
>
> Jim
>
>
It is just the rawhide policy, along with the rawhide docker-selinux 
package.

Then add the policy module above.

Re: Strange AVC with latest rawhide kernel.

[Paul Moore]

On Fri, Feb 26, 2016 at 10:49 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On 02/26/2016 10:46 AM, Paul Moore wrote:
>> On Fri, Feb 26, 2016 at 7:54 AM, Daniel J Walsh <dwalsh@redhat.com> wrote:
>>> On Thu, 2016-02-25 at 15:54 -0500, Stephen Smalley wrote:
>>>> On 02/25/2016 03:28 PM, Daniel J Walsh wrote:
>>>>>
>>>>> Currently typebounds only allows one instance.
>>>>
>>>> It is a hierarchy, where each child has a single parent.  So you can
>>>> define hierarchies like:
>>>> typebounds unconfined_t docker_t;
>>>> typebounds docker_t svirt_lxc_net_t;
>>>> and then they can both transition because they are both ancestors.
>>>
>>> Awesome idea.
>>
>> Would that resolve all your problems Dan with Docker, runc, etc.?
>> From our discussions the other day I thought you needed the ability to
>> transition to svirt_lxc_net_t from domains other than unconfined_t and
>> docker_t ... or was I misunderstanding you?
>
> Note that it is only exec-based transitions that are affected by
> NO_NEW_PRIVS, so one can always leverage dynamic transitions (i.e. setcon)
> without requiring typebounds.

Sure, but I really dislike recommending the use of setcon().

-- 
paul moore
www.paul-moore.com

Re: Strange AVC with latest rawhide kernel.

[Daniel J Walsh]

On Fri, 2016-02-26 at 12:13 -0500, Paul Moore wrote:
> On Fri, Feb 26, 2016 at 10:49 AM, Stephen Smalley <sds@tycho.nsa.gov>
> wrote:
> > 
> > On 02/26/2016 10:46 AM, Paul Moore wrote:
> > > 
> > > On Fri, Feb 26, 2016 at 7:54 AM, Daniel J Walsh <dwalsh@redhat.co
> > > m> wrote:
> > > > 
> > > > On Thu, 2016-02-25 at 15:54 -0500, Stephen Smalley wrote:
> > > > > 
> > > > > On 02/25/2016 03:28 PM, Daniel J Walsh wrote:
> > > > > > 
> > > > > > 
> > > > > > Currently typebounds only allows one instance.
> > > > > It is a hierarchy, where each child has a single parent.  So
> > > > > you can
> > > > > define hierarchies like:
> > > > > typebounds unconfined_t docker_t;
> > > > > typebounds docker_t svirt_lxc_net_t;
> > > > > and then they can both transition because they are both
> > > > > ancestors.
> > > > Awesome idea.
> > > Would that resolve all your problems Dan with Docker, runc, etc.?
> > > From our discussions the other day I thought you needed the
> > > ability to
> > > transition to svirt_lxc_net_t from domains other than
> > > unconfined_t and
> > > docker_t ... or was I misunderstanding you?
> > Note that it is only exec-based transitions that are affected by
> > NO_NEW_PRIVS, so one can always leverage dynamic transitions (i.e.
> > setcon)
> > without requiring typebounds.
> Sure, but I really dislike recommending the use of setcon().
> 


Definitely would not work in the case of go, since fork/exec are pretty
much the same command.

Re: Strange AVC with latest rawhide kernel.

[Daniel J Walsh]

On Fri, 2016-02-26 at 10:46 -0500, Paul Moore wrote:
> On Fri, Feb 26, 2016 at 7:54 AM, Daniel J Walsh <dwalsh@redhat.com>
> wrote:
> > 
> > On Thu, 2016-02-25 at 15:54 -0500, Stephen Smalley wrote:
> > > 
> > > On 02/25/2016 03:28 PM, Daniel J Walsh wrote:
> > > > 
> > > > Currently typebounds only allows one instance.
> > > It is a hierarchy, where each child has a single parent.  So you
> > > can
> > > define hierarchies like:
> > > typebounds unconfined_t docker_t;
> > > typebounds docker_t svirt_lxc_net_t;
> > > and then they can both transition because they are both
> > > ancestors.
> > Awesome idea.
> Would that resolve all your problems Dan with Docker, runc, etc.?
> > 
> > From our discussions the other day I thought you needed the ability
> > to
> transition to svirt_lxc_net_t from domains other than unconfined_t
> and
> docker_t ... or was I misunderstanding you?
> 


Well the two ways we transition to svirt_sandbox_file_t is from runc
which will usually from either docker_t or from unconfined_t.  And from
docker.

We just need to label runc as docker_exec_t so that if you run it from
a systemd unit file the correct transitions will happen.

Re: Strange AVC with latest rawhide kernel.

[Paul Moore]

On Fri, Feb 26, 2016 at 11:31 AM, Daniel J Walsh <dwalsh@redhat.com> wrote:
> On Fri, 2016-02-26 at 10:46 -0500, Paul Moore wrote:
>> Would that resolve all your problems Dan with Docker, runc, etc.?
>> From our discussions the other day I thought you needed the ability
>> transition to svirt_lxc_net_t from domains other than unconfined_t
>> and docker_t ... or was I misunderstanding you?
>
> Well the two ways we transition to svirt_sandbox_file_t is from runc
> which will usually from either docker_t or from unconfined_t.  And from
> docker.
>
> We just need to label runc as docker_exec_t so that if you run it from
> a systemd unit file the correct transitions will happen.

Okay, easy enough.  Looks like we don't have to worry about this right now.

-- 
paul moore
www.paul-moore.com

Re: Strange AVC with latest rawhide kernel.

[Daniel J Walsh]

On Fri, 2016-02-26 at 12:15 -0500, Paul Moore wrote:
> On Fri, Feb 26, 2016 at 11:31 AM, Daniel J Walsh <dwalsh@redhat.com>
> wrote:
> > 
> > On Fri, 2016-02-26 at 10:46 -0500, Paul Moore wrote:
> > > 
> > > Would that resolve all your problems Dan with Docker, runc, etc.?
> > > From our discussions the other day I thought you needed the
> > > ability
> > > transition to svirt_lxc_net_t from domains other than
> > > unconfined_t
> > > and docker_t ... or was I misunderstanding you?
> > Well the two ways we transition to svirt_sandbox_file_t is from
> > runc
> > which will usually from either docker_t or from unconfined_t.  And
> > from
> > docker.
> > 
> > We just need to label runc as docker_exec_t so that if you run it
> > from
> > a systemd unit file the correct transitions will happen.
> Okay, easy enough.  Looks like we don't have to worry about this
> right now.
> 

Although I will probably need to change the policy from docker_* to
containerapp_* since we will need to apply this policy to all tools
that launch containers.  rkt, runc, docker, systemd-nspawn ...

Re: Strange AVC with latest rawhide kernel.

[Daniel J Walsh]

On Thu, 2016-02-25 at 14:47 -0500, Stephen Smalley wrote:
> On 02/25/2016 02:37 PM, Eric Paris wrote:
> > 
> > You added a type bounds right before this broke...  Does the parent
> > type have entrypoint? If not, maybe that's where it got stripped...
> That would match the behavior he described (although he should get
> an 
> audit message of the form op=security_compute_av reason=bounds.. in 
> audit.log or dmesg in that case).  The kernel automatically reduces 
> permissions as required by typebounds.  The corresponding logic
> never 
> made its way into the libsepol compute_av code, so audit2why
> wouldn't 
> know about it, and sesearch merely searches for TE rules; it doesn't
> do 
> anything about typebounds.  We should probably update libsepol 
> compute_av (for that, and eventually for xperms).

Eric is right.  I added the following policy and got the error again.

policy_module(mypol, 1.0)

require {
	type svirt_lxc_net_t;
	type docker_t;
}
typebounds docker_t svirt_lxc_net_t;


Then I added this policy and it worked.

policy_module(mypol, 1.0)

require {
	type svirt_lxc_net_t;
	type docker_t;
	type svirt_sandbox_file_t;
}
allow docker_t svirt_sandbox_file_t:file entrypoint;
typebounds docker_t svirt_lxc_net_t;

So typebounds removed the entrypoint access from svirt_lxc_net_t, but
none of the tools realized this.

Re: Strange AVC with latest rawhide kernel.

[Miroslav Grepl]

On 02/25/16 21:36, Daniel J Walsh wrote:
> On Thu, 2016-02-25 at 14:47 -0500, Stephen Smalley wrote:
>> On 02/25/2016 02:37 PM, Eric Paris wrote:
>>>
>>> You added a type bounds right before this broke...  Does the parent
>>> type have entrypoint? If not, maybe that's where it got stripped...
>> That would match the behavior he described (although he should get
>> an 
>> audit message of the form op=security_compute_av reason=bounds.. in 
>> audit.log or dmesg in that case).  The kernel automatically reduces 
>> permissions as required by typebounds.  The corresponding logic
>> never 
>> made its way into the libsepol compute_av code, so audit2why
>> wouldn't 
>> know about it, and sesearch merely searches for TE rules; it doesn't
>> do 
>> anything about typebounds.  We should probably update libsepol 
>> compute_av (for that, and eventually for xperms).
> 
> Eric is right.  I added the following policy and got the error again.
> 
> policy_module(mypol, 1.0)
> 
> require {
> 	type svirt_lxc_net_t;
> 	type docker_t;
> }
> typebounds docker_t svirt_lxc_net_t;
> 
> 
> Then I added this policy and it worked.
> 
> policy_module(mypol, 1.0)
> 
> require {
> 	type svirt_lxc_net_t;
> 	type docker_t;
> 	type svirt_sandbox_file_t;
> }
> allow docker_t svirt_sandbox_file_t:file entrypoint;
> typebounds docker_t svirt_lxc_net_t;

Were you looking for SELINUX_ERR in audit.log? This is a design of
typebounds -> bounding domains need to have required bounded permissions.

So I have

type bounded_t;
type bounding_t;

an I am getting

type=SELINUX_ERR msg=audit(1456737948.283:273): op=security_compute_av
reason=bounds scontext=system_u:system_r:bounded_t:s0-s0:c0.c1023
tcontext=system_u:object_r:bin_t:s0 tclass=file perms=entrypoint

in my test because I am missing

allow bounding_t bin_t:file entrypoint;

It is also a reason why it is so hard to make sandbox working with
typebounds. Of course it is more about the current policy language and
his limitations and we will challenge them also here.

> 
> So typebounds removed the entrypoint access from svirt_lxc_net_t, but
> none of the tools realized this.
> 



-- 
Miroslav Grepl
Senior Software Engineer, SELinux Solutions
Red Hat, Inc.

Re: Strange AVC with latest rawhide kernel.

[Daniel J Walsh]

On Thu, 2016-02-25 at 13:18 -0500, Stephen Smalley wrote:
> On 02/25/2016 01:02 PM, Daniel J Walsh wrote:
> > 
> > audit2allow -wla
> > type=AVC msg=audit(1456422969.279:1434): avc:  denied  { entrypoint
> > }
> > for  pid=23847 comm="exe" path="/usr/bin/bash" dev="dm-2"
> > ino=25165968
> > scontext=system_u:system_r:svirt_lxc_net_t:s0:c337,c895
> > tcontext=system_u:object_r:svirt_sandbox_file_t:s0:c337,c895
> > tclass=file permissive=0
> > 	Was caused by:
> > 		Unknown - would be allowed by active policy
> > 		Possible mismatch between this policy and the one under
> > which the audit message was generated.
> > 
> > 		Possible mismatch between current in-memory boolean
> > settings vs. permanent ones.
> > 
> > When trying to run a docker container on Rawhide, I am seeing this
> > AVC.
> > The policy as audit2allow -w shows allows svirt_sandbox_file_t as
> > an
> > entrypoint for svirt_lxc_net_t.
> > 
> > # sesearch -A -s svirt_lxc_net_t -t svirt_sandbox_file_t -c file -p
> > entrypoint
> > Found 1 semantic av rules:
> >     allow svirt_sandbox_domain file_type : file entrypoint ;
> > 
> > But when I run try to start the container, docker blocks the
> > access.  I
> > don't see any constraints that would block this, and don't think
> > NO_NEW_PRIV is enabled any way, and I don't think it would be
> > involved
> > here.
> > 
> > Any idea why SELinux is blocking the access?
> Also, what does compute_av report for that (scontext, tcontext,
> tclass) 
> triple?
> 


Could this be a compiler issue?  I added the command directly and
compute_av still says it is not allowed. while sesearch says it is in
there.

Re: Strange AVC with latest rawhide kernel.

[Paul Moore]

On Thursday, February 25, 2016 01:02:49 PM Daniel J Walsh wrote:
> audit2allow -wla
> type=AVC msg=audit(1456422969.279:1434): avc:  denied  { entrypoint }
> for  pid=23847 comm="exe" path="/usr/bin/bash" dev="dm-2" ino=25165968
> scontext=system_u:system_r:svirt_lxc_net_t:s0:c337,c895
> tcontext=system_u:object_r:svirt_sandbox_file_t:s0:c337,c895
> tclass=file permissive=0
> 	Was caused by:
> 		Unknown - would be allowed by active policy
> 		Possible mismatch between this policy and the one under
> which the audit message was generated.
> 
> 		Possible mismatch between current in-memory boolean
> settings vs. permanent ones.
> 
> When trying to run a docker container on Rawhide, I am seeing this AVC.
> The policy as audit2allow -w shows allows svirt_sandbox_file_t as an
> entrypoint for svirt_lxc_net_t.
> 
> # sesearch -A -s svirt_lxc_net_t -t svirt_sandbox_file_t -c file -p
> entrypoint
> Found 1 semantic av rules:
>    allow svirt_sandbox_domain file_type : file entrypoint ; 
> 
> But when I run try to start the container, docker blocks the access.  I
> don't see any constraints that would block this, and don't think
> NO_NEW_PRIV is enabled any way, and I don't think it would be involved
> here. 

If you are making it as far as file:entrypoint then NNP shouldn't be an issue, 
you've already passed that SELinux control point.

Are you doing something new in Docker, or is the same code that worked on a 
previous kernel version?  If so, which kernel do you know worked?

-- 
paul moore
security @ redhat