* user_t more restrictive than sshd_t (e.g.)?
@ 2014-05-23 5:48 dE
2014-05-27 7:42 ` dE
0 siblings, 1 reply; 6+ messages in thread
From: dE @ 2014-05-23 5:48 UTC (permalink / raw)
To: selinux
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?
As an e.g. we may see systemctl.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: user_t more restrictive than sshd_t (e.g.)?
2014-05-23 5:48 user_t more restrictive than sshd_t (e.g.)? dE
@ 2014-05-27 7:42 ` dE
2014-05-27 13:32 ` [refpolicy] " Christopher J. PeBenito
0 siblings, 1 reply; 6+ messages in thread
From: dE @ 2014-05-27 7:42 UTC (permalink / raw)
To: selinux
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?
>
> As an e.g. we may see systemctl.
Is this concern real?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: user_t more restrictive than sshd_t (e.g.)?
2014-05-27 7:42 ` dE
@ 2014-05-27 13:32 ` Christopher J. PeBenito
0 siblings, 0 replies; 6+ messages in thread
From: Christopher J. PeBenito @ 2014-05-27 13:32 UTC (permalink / raw)
To: dE, selinux, Refpolicy Mail List
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?
>>
>> As an e.g. we may see systemctl.
>
> Is this concern real?
Moving thread to refpolicy mail list.
--
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* [refpolicy] user_t more restrictive than sshd_t (e.g.)?
@ 2014-05-27 13:32 ` Christopher J. PeBenito
0 siblings, 0 replies; 6+ messages in thread
From: Christopher J. PeBenito @ 2014-05-27 13:32 UTC (permalink / raw)
To: refpolicy
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?
>>
>> As an e.g. we may see systemctl.
>
> Is this concern real?
Moving thread to refpolicy mail list.
--
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* [refpolicy] user_t more restrictive than sshd_t (e.g.)?
2014-05-27 13:32 ` [refpolicy] " Christopher J. PeBenito
(?)
@ 2014-05-27 13:35 ` Christopher J. PeBenito
2014-05-31 5:25 ` dE
-1 siblings, 1 reply; 6+ messages in thread
From: Christopher J. PeBenito @ 2014-05-27 13:35 UTC (permalink / raw)
To: refpolicy
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [refpolicy] user_t more restrictive than sshd_t (e.g.)?
2014-05-27 13:35 ` Christopher J. PeBenito
@ 2014-05-31 5:25 ` dE
0 siblings, 0 replies; 6+ messages in thread
From: dE @ 2014-05-31 5:25 UTC (permalink / raw)
To: selinux
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-05-31 5:28 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-05-23 5:48 user_t more restrictive than sshd_t (e.g.)? dE
2014-05-27 7:42 ` dE
2014-05-27 13:32 ` Christopher J. PeBenito
2014-05-27 13:32 ` [refpolicy] " Christopher J. PeBenito
2014-05-27 13:35 ` Christopher J. PeBenito
2014-05-31 5:25 ` dE
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.