Re: Strange AVC with latest rawhide kernel.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


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



[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux