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

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

[Murray McAllister]

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

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

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.

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

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

[James Morris]

On Tue, 9 Sep 2008, Murray McAllister wrote:

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

This is a long sentence which I suspect general users would not easily 
understand.  Perhaps break it into two sentences, with the second as:

"The SELinux user identity is indicated in the user's process security 
context for that session."

Do you have a diagram breaking down the security context?  You could refer 
to it here.

> 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

This command will have different outputs depending on how the user is 
logged in, and there are seemingly (to the reader) two different ways to 
see the SELinux user mapping (a new concept to them at this point).

I suggest breaking it up so you first show the mapping via semanage, then 
show the output of 'id -Z' for one of the Unix logins, also perhaps 
explaining the flow:

- Linux users are mapped to SELinux users via policy

- user commences login
- pam_selinux maps the user and sets up the resulting security context
- user shell is launched in that context

> # /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.

I think you need to refer to a concrete example with the current text.

> 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

Why introduce unfamiliar terminology like "execute an object" ?  People 
execute applications.

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

Perhaps important to (re)state the security benefit of this, in that 
an unconfined user cannot override the security policy for a confined 
application just because they themselves are unconfined.


-- 
James Morris
<jmorris@namei.org>

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

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

[Daniel J Walsh]

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.


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

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

[Murray McAllister]

James Morris wrote:
> On Tue, 9 Sep 2008, Murray McAllister wrote:
> 
>> 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.
> 
> This is a long sentence which I suspect general users would not easily 
> understand.  Perhaps break it into two sentences, with the second as:
> 
> "The SELinux user identity is indicated in the user's process security 
> context for that session."

Would the following be enough:

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

> 
> Do you have a diagram breaking down the security context?  You could refer 
> to it here.

No. I will try to organize one. Is there anything specific that should 
be on it?

> 
>> 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
> 
> This command will have different outputs depending on how the user is 
> logged in, and there are seemingly (to the reader) two different ways to 
> see the SELinux user mapping (a new concept to them at this point).
> 
> I suggest breaking it up so you first show the mapping via semanage, then 
> show the output of 'id -Z' for one of the Unix logins, also perhaps 
> explaining the flow:
> 
> - Linux users are mapped to SELinux users via policy
> 
> - user commences login
> - pam_selinux maps the user and sets up the resulting security context
> - user shell is launched in that context

Would an example of adding a user (useradd newuser), logging in as 
newuser, then running "id -Z" help?

> 
>> # /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.
> 
> I think you need to refer to a concrete example with the current text.

An example of what a user sees (see above, adding newuser), or 
explaining what each field is?

> 
>> 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
> 
> Why introduce unfamiliar terminology like "execute an object" ?  People 
> execute applications.

I have removed these and replaced "subjects" with "processes", "execute 
object" with "execute application", and so on.

> 
>> 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.
> 
> Perhaps important to (re)state the security benefit of this, in that 
> an unconfined user cannot override the security policy for a confined 
> application just because they themselves are unconfined.

Sounds good. Thank you.

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

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

[Murray McAllister]

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.

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

[Murray McAllister]

Murray McAllister wrote:
> 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.

What sudo access does staff_t have?

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

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

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 5344 bytes --]

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@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
-- 
Dominick Grift <domg472@gmail.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 680 bytes --]

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

> What sudo access does staff_t have?

I think staff can transition to all privileged user domains

secadm,logadm,webadm,auditadm,unconfined,sysadm etc. You can verify this
in the staff role module in the source policy. staff_t may also be root
however this root as staff_t will have the same permission as staff_t as
unprivileged user.

> --
> 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.
-- 
Dominick Grift <domg472@gmail.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Daniel J Walsh]

Murray McAllister wrote:
> Murray McAllister wrote:
>> 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.
> 
> What sudo access does staff_t have?
None by default.  This is something that needs to be setup by the admin.
Out of the box staff_u can reach sysadm_r which allows him to become
sysadm_t.

If you want to setup staff_u to be able to reach unconfined_t through
sudo, My blog explains how.


http://danwalsh.livejournal.com/18578.html

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

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

[Daniel J Walsh]

Dominick Grift wrote:
> On Mon, 2008-09-15 at 12:12 +1000, Murray McAllister wrote:
> 
>> What sudo access does staff_t have?
> 
> I think staff can transition to all privileged user domains
> 
> secadm,logadm,webadm,auditadm,unconfined,sysadm etc. You can verify this
> in the staff role module in the source policy. staff_t may also be root
> however this root as staff_t will have the same permission as staff_t as
> unprivileged user.
> 
Well not in targeted policy.
Out of the box
sesearch --role_allow | grep staff
   allow staff_r sysadm_r;
   allow system_r staff_r;
   allow staff_r unconfined_r;
   allow staff_r webadm_r;

This means staff_r can become sysadm_r, unconfined_r and webadm_r in
Fedora 9/10 targeted policy.
>> --
>> 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.


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

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

[Murray McAllister]

Dominick Grift wrote:
> 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.
If I called this an SELinux group, would it cause confusion to users 
seeing "SELinux user" (instead of group) in the output of semanage user 
and semanage login?

>>  
>> 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.
I moved the text around a bit:

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

[output]

By default, on Fedora 10, Linux users are mapped to the SELinux 
__default__ login, which is mapped to the SELinux unconfined_u user. The 
following defines the default-mapping:

__default__               unconfined_u              s0-s0:c0.c1023
> 
> 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.
I think we talked on irc and you mentioned you might have changed this 
to user_u. I installed a new rawhide machine today, and __default__ and 
root are mapped to unconfined_u.
> 
>>  
>> 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.
Thanks! What about:

The following example demonstates adding a new Linux user, and that 
Linux user being mapped to the SELinux unconfined_u user. It assumes 
that the Linux root user is running unconfined, as it does by default on 
Fedora 10:
> 
>> 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.
Do I need to add a note about this, or is it clear that it is mapped to 
unconfined_u by default?
> 
>> [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.
I added a new user (useradd) and they were assigned to all categories by 
default.
> 
>> [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.

Thanks :)

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

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

[Murray McAllister]

Daniel J Walsh wrote:
> Murray McAllister wrote:
>> Murray McAllister wrote:
>>> 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.
>> What sudo access does staff_t have?
> None by default.  This is something that needs to be setup by the admin.
> Out of the box staff_u can reach sysadm_r which allows him to become
> sysadm_t.
Would a bullet point something like the following be okay:

* by default, Linux users in the staff_t domain do not have permissions 
to execute applications with /usr/bin/sudo. These permissions must be 
configured by an administrator.
> 
> If you want to setup staff_u to be able to reach unconfined_t through
> sudo, My blog explains how.
> 
> 
> http://danwalsh.livejournal.com/18578.html


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