Re: user guide draft: "Confined and Unconfined User Domains" review

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2008-09-15 at 11:27 +1000, Murray McAllister wrote:

> Hi,
> 
> I have made some changes:
> 
> Confined and Unconfined Users
> 
> Each Linux user is mapped to an SELinux user via SELinux policy. This

I would call it SEinux user group because you can map several users to
the same SELinux user group.
>  
> allows Linux users to inherit the restrictions on SELinux users. By 
> default, on Fedora 10, Linux users are mapped to the SELinux

I would say the Linux users are by default mapped to the __default__
login, which (usually) in Fedora is mapped to unconfined_u SELinux user
group.

Please note though that currently __default__ login is mapped to user_u
SELinux usr group in rawhide. You can verify this in rawhide by semanage
login -a. I do not now if this can be considered a bug.

>  
> 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

This may in many cases be right however in SELinux world root is not all
powerfull by itself. in this example you assume that root runs in the
unconfined_t domain, which it does by default however one can run root
in other domains as well.

> 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:
> 

That is if __default__ login is mapped to unconfined SELinux user group.

> [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:

I am not sure if by default that user is assigned all categories.

> [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@xxxxxxxxxxxxx with
> the words "unsubscribe selinux" without quotes as the message.
-- 
Dominick Grift <domg472@xxxxxxxxx>

Attachment: signature.asc
Description: This is a digitally signed message part


[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux