On 11/07/2016 09:50 AM, mm19827 wrote: > > > On 11/07/2016 03:35 PM, Stephen Smalley wrote: >> >>> Moreover, in order not to compromise the functionality of /bin/bar, I >>> would need to allow bar_t the same access as unconfined_t (at least as a >>> first approximation). The fact is that, although I can trust /bin/bar, >>> it is not selinux-aware. >> >> I wouldn't do that; otherwise any security gains you are getting are >> illusory since bar is equivalent to unconfined. It isn't that hard to >> define a real confined domain for a program. > > I agree that defining a real confined domain for /bin/bar is a better > approach. > It is not clear to me that any security gains would be illusory: even if > /bin/bar (from bar_t) has effectively unconfined access, still /bin/foo > (i.e. foo_t) could only access bar_t, and not unconfined_t. I suppose that's true, depending on what it is that you have to allow between foo_t and bar_t, e.g. you can allow foo_t to connect to a bar_t socket or similar without allowing it to connect to unconfined_t sockets. If you truly want bar_t to be unconfined, you can always just have it call the unconfined_domain() interface in refpolicy, e.g. unconfined_domain(bar_t), and it will inherit all of the unconfined domain rules. >> >> Generally the simplest approach is to define a stub .te file for your >> domain, include a permissive declaration for it (permissive bar_t;), and >> then derive a policy from the resulting avc: > Thanks for the hint of the stub .te file. > The only issue here is that I would need to find a way to trigger all > possible avc's from /bin/bar, which is not straightforward. Yes, it is better if you have some idea of the expected functionality of bar, whether from source code, static analysis of the binary, strace, or documentation, and can then define up front policy that corresponds. _______________________________________________ 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.
