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