From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Tue, 27 May 2014 09:35:47 -0400
Subject: [refpolicy] user_t more restrictive than sshd_t (e.g.)?
In-Reply-To: <538493D3.6010305@tresys.com>
References: <537EE13B.7090603@gmail.com> <538441F4.3010104@gmail.com>
	<538493D3.6010305@tresys.com>
Message-ID: <538494B3.2030700@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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.


-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com