Re: [refpolicy] user_t more restrictive than sshd_t (e.g.)?

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

 



On 05/27/14 19:05, Christopher J. PeBenito wrote:
On 05/27/2014 09:32 AM, Christopher J. PeBenito wrote:
On 05/27/2014 03:42 AM, dE wrote:
On 05/23/14 11:18, dE wrote:
As we know, the user_r does not allow many processes to have high privilege types (system_t for e.g. which's tailored for a single program named X), if such a process is executed, it'll have a type of user_t.

However system_t specifies restrictions on the program exactly as per X's specifications -- it wont allow the program to do anything outside what's it supposed to do.

But that's not the same for user_t -- this type is generic and there are many things that user_t allows which system_t does not.

This may form a security vector; a vulnerable program which should run as system_t but is not run cause user_r does not allow that type, this allows the program to do many things which it's not designed to do; so basically this bypasses SELinux restrictions as put on by system_t.

So, is there any way to prevent this form happening -- or can we specify in the policy what type to run the program as when it's run by a user with role user_r or any other user which is not allowed system_t?
If there is an exec() that causes a domain/role transition to an invalid context, the exec() will fail.  The program won't run.



Thanks for forwarding the response.

Unfortunately I've been going thorough more related confusion, so I'm sorting them out.
_______________________________________________
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