All of lore.kernel.org
 help / color / mirror / Atom feed
From: Murray McAllister <mmcallis@redhat.com>
To: Daniel J Walsh <dwalsh@redhat.com>
Cc: James Morris <jmorris@namei.org>, SE Linux <selinux@tycho.nsa.gov>
Subject: Re: user guide draft: "Confined and Unconfined User Domains" review
Date: Mon, 15 Sep 2008 11:27:38 +1000	[thread overview]
Message-ID: <48CDBA0A.3000801@redhat.com> (raw)
In-Reply-To: <48C67DCD.2030104@redhat.com>

Daniel J Walsh wrote:
> Murray McAllister wrote:
>> Hi,
>>
>> The following is a draft of the "Confined and Unconfined User Domains"
>> section for the SELinux User Guide. Any comments and corrections are
>> appreciated.
>>
>> This is the last part of intro text.
>>
>> Thanks.
>>
>>
>> Confined and Unconfined User Domains
>>
>> Each Linux user account is mapped to an SELinux user identity when a
>> user login session is created, and the mapped SELinux user identity is
>> used in the security context for processes in that session. By default,
>> on Fedora 10, Linux users are mapped to the SELinux unconfined_u user.
>> This is seen by running the id -Z and /usr/sbin/semanage login -l commands:
>>
>> # id -Z
>> unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
>> # /usr/sbin/semanage login -l
>>
>> Login Name                SELinux User              MLS/MCS Range
>>
>> __default__               unconfined_u              s0-s0:c0.c1023
>> root                      unconfined_u              s0-s0:c0.c1023
>> system_u                  system_u                  s0-s0:c0.c1023
>>
>> The first row, __default__, defines that any new Linux users created
>> that are not specifically mapped to an SELinux user, are mapped to the
>> SELinux unconfined_u user. For a description of each column, refer to
>> Chapter 3, SELinux Contexts. Unconfined Linux users are subject to
>> executable and writeable memory checks, and are also restricted by MCS
>> (and MLS, if the MLS policy is used). If they execute an object that the
>> SELinux policy defines can transition from the unconfined_t domain to
>> its own confined domain, the unconfined Linux users are still subject to
>> the restrictions of that confined domain.
>>
>> The following confined user domains are available in Fedora 10:
>>
>> guest_t: The guest_t domain is used for minimal-privileged Linux users.
> guest_u:  The guest_u SELinux user will default to the guest_t type when
> logging in. The guest_t domain ...
>> Linux users in this domain are not allowed to use the X Window System,
>> run set user ID (setuid) applications, and do not have network access.
>> For example, Permission denied errors are returned when using the ping
>> and ssh commands. These users are allowed a log in via a terminal
>> (including ssh).
>>
> Examples of setuid applications su, sudo.  I think you should say that
> the power of this is that they can never become root.
> 
> guest_t, xguest_t, user_t are also prevented by default from executing
> code in their home directory or tmp directories, preventing them from
> execuing programs in directories they can write to.
> 
>> xguest_t: The xguest_t domain is also for minimal-privileged Linux
>> users, but lets them use the X Window System. Linux users in this domain
>> are not allowed to run setuid applications, and the only network access
>> allowed is Firefox connecting to web pages. These users are allowed to
>> log in via the X Window System and a terminal.
>>
>> user_t: The user_t domain is for standard Linux users. Linux users in
>> this domain are not allowed to run setuid applications. These users are
>> allowed to log in via the X Window System and a terminal, and have full
>> network access.
>>
>> [I think I got this wrong. I got permission denied when trying to use
>> ping as a user_u user (useradd -Z user_u test)]
>>
> ping is a setuid application.
>> staff_t: The staff_t domain is similar to user_t, except that Linux
>> users in this domain are allowed to run the setuid sudo application.
>>
> These should all be guest_u, xguest_u, staff_u, user_u.
> 
> Finally saying they can not run setuid applications is somewhat
> incorrect.   The real prevention is they can not run setuid apps without
> a defined transition.  So all of the users can run passwd as an example,
> which is a setuid app.  But they can not run any application that does
> not allow a transition.
>> -- 
>> This message was distributed to subscribers of the selinux mailing list.
>> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov
>> with
>> the words "unsubscribe selinux" without quotes as the message.
> 

Hi,

I have made some changes:

Confined and Unconfined Users

Each Linux user is mapped to an SELinux user via SELinux policy. This 
allows Linux users to inherit the restrictions on SELinux users. By 
default, on Fedora 10, Linux users are mapped to the SELinux 
unconfined_u user. This Linux user mapping is seen by running the 
/usr/sbin/semanage login -l command as the Linux root user:

# /usr/sbin/semanage login -l

Login Name                SELinux User              MLS/MCS Range

__default__               unconfined_u              s0-s0:c0.c1023
root                      unconfined_u              s0-s0:c0.c1023
system_u                  system_u                  s0-s0:c0.c1023

The following defines the default-mapping:

__default__               unconfined_u              s0-s0:c0.c1023

The following example demonstates adding a new Linux user, and that 
Linux user being mapped to the SELinux unconfined_u user:

1. As the Linux root user, create a new Linux user named newuser:

# /usr/sbin/useradd newuser

2. As the Linux root user, assign a password to the Linux newuser user:

# passwd newuser
Changing password for user newuser.
New UNIX password: Enter a password
BAD PASSWORD: it is based on a dictionary word
Retype new UNIX password: Enter the same password again
passwd: all authentication tokens updated successfully.

3. Log out of your current session, and log in as the Linux newuser user.

4. When you log in, pam_selinux maps the Linux user to an SELinux user 
(in this case, unconfined_u), and sets up the resulting SELinux context. 
The Linux user's shell is then launched with this SELinux context. To 
view the SELinux context for a Linux user, run the id -Z command:

[newuser@localhost ~]$ id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

If mcstrans is running, s0-s0:c0.c1023 is translated to 
SystemLow-SystemHigh:

[newuser@localhost ~]$ id -Z
unconfined_u:unconfined_r:unconfined_t:SystemLow-SystemHigh

Confined and unconfined Linux users are subject to executable and 
writeable memory checks, and are also restricted by MCS (and MLS, if the 
MLS policy is used). If unconfined Linux users execute an application 
that SELinux policy defines can transition from the unconfined_t domain 
to its own confined domain, unconfined Linux users are still subject to 
the restrictions of that confined domain. The security benefit of this 
is that, even though a Linux user is running unconfined, they can not 
override the SELinux policy for a confined application, just because 
they (the user) are unconfined.

The following confined SELinux users are available in Fedora 10:

[ I have put most of this into a table, with with colums: User, Domain, 
X Window System, su and sudo, Execute in home directory and /tmp, 
Networking, and used ticks+crosses to minimize too much text]

* Linux users in the guest_t, xguest_t, and user_t domains can only run 
set user ID (setuid) applications if SELinux policy permits it (such as 
passwd). They can not run the su and /usr/bin/sudo setuid applications, 
and therefore, can not become the Linux root user with these applications.

* Linux users in the guest_t domain have no network access.

* The only network access Linux users in the xguest_t domain have is 
Firefox connecting to web pages.

* By default, Linux users in the guest_t, xguest_t, and user_t domains 
can not execute applications in their home directories or /tmp/, 
preventing them from executing applications (which inherit users' 
permissions) in directories that they have write access to. This 
prevents flawed or malicious applications from modifying files users' own.

* Linux users in the guest_t can only log in via a terminal (including 
ssh).

* Linux users in the xguest_t, user_t and staff_t domains can log in via 
the X Window System and a terminal.


Thanks for your help.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

  reply	other threads:[~2008-09-15  1:32 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-09  7:19 user guide draft: "Confined and Unconfined User Domains" review Murray McAllister
2008-09-09 10:29 ` James Morris
2008-09-11 10:40   ` Murray McAllister
2008-09-09 13:44 ` Daniel J Walsh
2008-09-15  1:27   ` Murray McAllister [this message]
2008-09-15  2:12     ` Murray McAllister
2008-09-15 11:17       ` Dominick Grift
2008-09-15 13:07         ` Daniel J Walsh
2008-09-15 13:03       ` Daniel J Walsh
2008-09-17  5:53         ` Murray McAllister
2008-09-15 11:10     ` Dominick Grift
2008-09-17  5:43       ` Murray McAllister

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=48CDBA0A.3000801@redhat.com \
    --to=mmcallis@redhat.com \
    --cc=dwalsh@redhat.com \
    --cc=jmorris@namei.org \
    --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.