All of lore.kernel.org
 help / color / mirror / Atom feed
From: dE <de.techno@gmail.com>
To: selinux@tycho.nsa.gov
Subject: Re: user_t more restrictive than sshd_t (e.g.)?
Date: Tue, 27 May 2014 13:12:44 +0530	[thread overview]
Message-ID: <538441F4.3010104@gmail.com> (raw)
In-Reply-To: <537EE13B.7090603@gmail.com>

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?

  reply	other threads:[~2014-05-27  7:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-23  5:48 user_t more restrictive than sshd_t (e.g.)? dE
2014-05-27  7:42 ` dE [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=538441F4.3010104@gmail.com \
    --to=de.techno@gmail.com \
    --cc=selinux@tycho.nsa.gov \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.