From: justinmattock@gmail.com (Justin P. mattock)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] user vs unconfined
Date: Mon, 08 Mar 2010 18:25:55 -0800 [thread overview]
Message-ID: <4B95B1B3.5080308@gmail.com> (raw)
In-Reply-To: <201003091314.03493.russell@coker.com.au>
On 03/08/2010 06:14 PM, Russell Coker wrote:
> Why do unconfined_t and user_t use the same file types for almost everything
> in the latest policy?
>
> This means that if an unconfined user has bad Unix permissions on their home
> directory then user_t can replace a file that will be executed and therefore
> gain unconfined_t access.
>
> So is there any benefit in using user_t in such a scheme? If there isn't a
> benefit, and as almost all users of the Fedora policy will only use
> unconfined_t for user sessions it seems that the thing to do would be to
> restore the previous separation of user_t, staff_t, sysadm_t, and
> unconfined_t for those who need it as it won't actually affect the Fedora
> users.
>
> Or of course I could just maintain a private fork of the policy for Debian.
>
> Since 2002 the Debian policy has denied root:user_r:user_t the ability to take
> over the system and I plan to keep it that way.
>
doesn't matter to me(although my opinion probably doesn't matter).
let me know I can load up the latest policy and see.
Justin P. Mattock
next prev parent reply other threads:[~2010-03-09 2:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-09 2:14 [refpolicy] user vs unconfined Russell Coker
2010-03-09 2:25 ` Justin P. mattock [this message]
2010-03-09 6:39 ` Michal Svoboda
2010-03-09 13:58 ` Christopher J. PeBenito
2010-03-23 2:16 ` Russell Coker
2010-03-25 15:46 ` Christopher J. PeBenito
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=4B95B1B3.5080308@gmail.com \
--to=justinmattock@gmail.com \
--cc=refpolicy@oss.tresys.com \
/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.