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?
_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
