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?
_______________________________________________
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.
