user guide drafts: "Working with SELinux" sections

user guide drafts: "Working with SELinux" sections

[Murray McAllister]

Hi,

Apologies if I sent this twice.

The following is a draft of the "Installing and Upgrading SELinux 
Packages", "Main Configuration File", and "Enabling and Disabling 
SELinux" sections. Any comments and corrections are appreciated.

Thanks.

Working with SELinux

The following sections [fill in when finished]

Installing and Upgrading SELinux Packages

In Fedora 10, the SELinux packages are installed by default unless they 
are manually excluded during installation. The following is a brief 
description of the main packages:

* policycoreutils: provides utilities, such as semanage, restorecon, and 
load_policy, for operating and managing SELinux.

* selinux-policy: provides the SELinux Reference Policy. The SELinux 
Reference Policy is a complete SELinux policy, and is used as a basis 
for other policies, such as the SELinux targeted policy. Refer to the 
Tresys Technology SELinux Reference Policy[1] page for further 
information. The selinux-policy-devel package provides development 
tools, such as /usr/share/selinux/devel/policygentool and 
/usr/share/selinux/devel/policyhelp, as well as example policy files. 
This package has been merged into the the selinux-policy package.

* selinux-policy-[policy]: provides SELinux policies. For targeted 
policy, install selinux-policy-targeted. For MLS, install 
selinux-policy-mls. The strict policy was merged in Fedora 9, allowing 
confined and unconfined users to co-exist on the same system.

* setroubleshoot-server: translates denial messages, produced when 
access is denied by SELinux, into detailed descriptions that are viewed 
with sealert (which is provided by this package).

* setroubleshoot: a graphical user interface for viewing denials that 
are translated by setroubleshoot-server.

* mcstrans: translates levels, such as s0-s0:c0.c1023, to an easier to 
read form, such as SystemLow-SystemHigh. This package is not installed 
by default.

To install packages in Fedora 10, as the Linux root user, run the yum 
install package-name command. For example, to install the mcstrans 
package, run the yum install mcstrans command.

To upgrade all installed packages in Fedora 10, as the Linux root user, 
run the yum update command. To update individual packages, run the yum 
update package-name command. For example, to only upgrade the mcstrans 
package, run the yum update mcstrans command.

Refer to Managing Software with yum[2] for information about using yum 
to manage packages.

Main Configuration File

The /etc/selinux/config file is the main SELinux configuration file. It 
controls the SELinux mode and the SELinux policy to use:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of these two values:
#       targeted - Targeted processes are protected,
#       mls - Multi Level Security protection.
SELINUXTYPE=targeted

SELINUX=enforcing: The SELINUX option sets the mode SELinux runs in. 
SELinux has three modes: enforcing, permissive, and disabled. When using 
enforcing mode, SELinux denies access based on SELinux policy rules, and 
denial messages are logged. When using permissive mode, SELinux policy 
is not enforced, but denials are logged for actions that would have been 
denied if running in enforcing mode. When using disabled mode, SELinux 
is disabled (the SELinux module is not registered with the Linux 
kernel), and only DAC rules are used. For example, to configure SELinux 
to use permissive mode, configure SELINUX=permissive in 
/etc/selinux/config, and reboot your system.

SELINUXTYPE=targeted: The SELINUXTYPE option sets the SELinux policy to 
use. Targeted policy is the default policy used. Only change this option 
if you want to use the MLS policy. To use the MLS policy, install the 
selinux-policy-mls package; configure SELINUXTYPE=mls in 
/etc/selinux/config; and reboot your system.

# are there any other configuration files that should be mentioned?

Enabling and Disabling SELinux

Use the getenforce or sestatus commands to check the status of SELinux. 
The getenforce command returns Enforcing, Permissive, or Disabled. The 
getenforce command returns Enforcing when SELinux is enabled (SELinux 
policy rules are enforced):

$ getenforce
Enforcing

The getenforce command returns Permissive when SELinux is enabled, but 
SELinux policy rules are not enforced, and only DAC rules are used. The 
getenforce command returns Disabled if SELinux is disabled.

The sestatus command returns the SELinux status and the SELinux policy 
being used:

$ sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 23
Policy from config file:        targeted

SELinux status: enabled is returned when SELinux is enabled. Current 
mode: enforcing is returned when SELinux is running in enforcing mode. 
Policy from config file: targeted is returned when the SELinux targeted 
policy is used.

Enabling SELinux

On systems with SELinux disabled, the SELINUX=disabled option is 
configured in /etc/selinux/config:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of these two values:
#       targeted - Targeted processes are protected,
#       mls - Multi Level Security protection.
SELINUXTYPE=targeted

Also, the getenforce command returns Disabled:

$ getenforce
Disabled

To enable SELinux:

1. Use the rpm -qa | grep selinux, rpm -q policycoreutils, and rpm -qa | 
grep setroubleshoot commands to confirm that the SELinux packages are 
installed. The following packages must be installed: 
selinux-policy-targeted, selinux-policy, libselinux, libselinux-python, 
libselinux-utils, policycoreutils, setroubleshoot-server, 
setroubleshoot-plugins. If these packages are not installed, as the 
Linux root user, install them via the yum install package-name command. 
The following packages are optional: policycoreutils-gui, 
setroubleshoot, selinux-policy-devel, and mcstrans.

# is there a better way to see if these packages are installed?

2. Before SELinux is enabled, each file on the file system must be 
labeled with an SELinux context. Before this happens, confined domains 
may be denied access, preventing your system from booting correctly. To 
prevent this, configure SELINUX=permissive in /etc/selinux/config:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - No SELinux policy is loaded.
SELINUX=permissive
# SELINUXTYPE= can take one of these two values:
#       targeted - Targeted processes are protected,
#       mls - Multi Level Security protection.
SELINUXTYPE=targeted

3. As the Linux root user, run the reboot command to restart the system. 
During the next boot, the file system is labeled. During this process, 
all files are labeled with an SELinux context:

*** Warning -- SELinux targeted policy relabel is required.
*** Relabeling could take a very long time, depending on file
*** system size and speed of hard drives.
****

Each * character on the bottom line represents 1000 files that have been 
labeled. In the above example, four * characters represent 4000 files 
have been labeled. The time it takes to label all files depends upon the 
number of files on the system, and the speed of the hard disk drives. On 
modern systems, this process can take as little as 10 minutes.

4. In permissive mode, SELinux policy is not enforced, but denials are 
still logged for actions that would have been denied if running in 
enforcing mode. Before changing to enforcing mode, as the Linux root 
user, run the grep "SELinux is preventing" /var/log/messages command to 
confirm that SELinux did not deny actions during the last boot. If 
SELinux did not deny actions during the last boot, this command does not 
return any output.

# should users run something like "> /var/log/messages" before rebooting?

# are there common denials that should be listed here for boot problems?

5. If there were no denial messages in /var/log/messages, configure 
SELINUX=enforcing in /etc/selinux/config:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of these two values:
#       targeted - Targeted processes are protected,
#       mls - Multi Level Security protection.
SELINUXTYPE=targeted

6. Reboot your system. After reboot, confirm that the getenforce command 
returns Enforcing:

$ getenforce
Enforcing

7. As the Linux root user, run the semanage login -l command to confirm 
that the mapping between SELinux and Linux users is correct. The output 
should be as follows:

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

If this is not the case, run the following commands as the Linux root 
user to fix the user mappings:

# semanage user -a -S targeted -P user -R "unconfined_r system_r" -r 
s0-s0:c0.c1023 unconfined_u
# semanage login -m -S targeted  -s "unconfined_u" -r s0-s0:c0.c1023 
__default__
# semanage login -m -S targeted  -s "unconfined_u" -r s0-s0:c0.c1023 root
# semanage user -a -S targeted  -P user -R guest_r guest_u
# semanage user -a -S targeted  -P user -R xguest_r xguest_u

It is safe to ignore the SELinux-user SELinux user is already defined 
warnings if they occur, where SELinux-user can be unconfined_u, guest_u, 
or xguest_u.

Disabling SELinux

To disable SELinux, configure SELINUX=disabled in /etc/selinux/config:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of these two values:
#       targeted - Targeted processes are protected,
#       mls - Multi Level Security protection.
SELINUXTYPE=targeted

Reboot your system. After reboot, confirm that the getenforce command 
returns Disabled:

$ getenforce
Disabled

[1] http://oss.tresys.com/projects/refpolicy
[2] http://docs.fedoraproject.org/yum/en/

--
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 drafts: "Working with SELinux" sections

[Valdis.Kletnieks]

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

On Tue, 23 Sep 2008 16:16:00 +1000, Murray McAllister said:

> * selinux-policy-[policy]: provides SELinux policies. For targeted 
> policy, install selinux-policy-targeted. For MLS, install 
> selinux-policy-mls. The strict policy was merged in Fedora 9, allowing 
> confined and unconfined users to co-exist on the same system.

Strict was merged with what, exactly? (This threw me for a loop when
strict evaporated out of rawhide, before I figured out that MLS was what
I needed as the replacement - for most of my boxes, I don't actually *need*
the MLS/MCS stuff, I just need to not have an 'unconfined' on the box.  For
a *few* others, the MCS stuff is handy.  And actual MLS is barely on the
radar here...)

> denied if running in enforcing mode. When using disabled mode, SELinux 
> is disabled (the SELinux module is not registered with the Linux 
> kernel), and only DAC rules are used.

Might want to note that operating in disabled mode probably means you want
to do a relabel if you re-enable SELinux, because any files created/modified
while running disabled are probably unlabeled.

> SELINUXTYPE=targeted: The SELINUXTYPE option sets the SELinux policy to 
> use. Targeted policy is the default policy used. Only change this option 
> if you want to use the MLS policy. To use the MLS policy, install the 
> selinux-policy-mls package; configure SELINUXTYPE=mls in 
> /etc/selinux/config; and reboot your system.

Someplace, you want to discuss why one might want to use MLS (whether as the
replacement for the old 'strict' policy where everything ran confined as
opposed to 'targeted', or if you have an actual use case for the MLS/MCS
features).

> 4. In permissive mode, SELinux policy is not enforced, but denials are 
> still logged for actions that would have been denied if running in 
> enforcing mode. Before changing to enforcing mode, as the Linux root 
> user, run the grep "SELinux is preventing" /var/log/messages command to 

Erm. What *exactly* produces that entry in /var/log/messages?  All my
AVC stuff ends up in auditd.  Or is this just because the setroubleshoot
RPMs aren't *quite* as mandatory as you noted above, and I don't see those
messages because I don't have them installed *and enabled*? (Gotta watch
out for those pesky 'chkconfig off' ;)

> # should users run something like "> /var/log/messages" before rebooting?

This is a good way to lose potentially important log entries.  Also,
note that if the box is running syslog-ng, the file might be called
/var/log/messages.YYMMDD or similar (very handy, that - no need to worry
about cronjobs rolling the files).

> 5. If there were no denial messages in /var/log/messages, configure 
> SELINUX=enforcing in /etc/selinux/config:

You need to discuss the very possible case that there *were* denial messages.
How do you fix them?  audit2allow is *one* option, as is correctly labelling
files (if you have them in a non-standard place, you probably want to be doing
an 'semanage fcontext -a').  But blindly doing either of those is a good way to
hose yourself gloriously.

> 7. As the Linux root user, run the semanage login -l command to confirm 
> that the mapping between SELinux and Linux users is correct. The output 
> should be as follows:

Also handy at this point - explain how to add additional SELinux userids
and map login IDs to them (you can't really do anything with the MLS/MCS
support if everybody is either user_u or staff_u).

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: user guide drafts: "Working with SELinux" sections

[Stephen Smalley]

On Thu, 2008-09-25 at 23:30 -0400, Valdis.Kletnieks@vt.edu wrote:
> On Tue, 23 Sep 2008 16:16:00 +1000, Murray McAllister said:
> 
> > * selinux-policy-[policy]: provides SELinux policies. For targeted 
> > policy, install selinux-policy-targeted. For MLS, install 
> > selinux-policy-mls. The strict policy was merged in Fedora 9, allowing 
> > confined and unconfined users to co-exist on the same system.
> 
> Strict was merged with what, exactly? (This threw me for a loop when
> strict evaporated out of rawhide, before I figured out that MLS was what
> I needed as the replacement - for most of my boxes, I don't actually *need*
> the MLS/MCS stuff, I just need to not have an 'unconfined' on the box.  For
> a *few* others, the MCS stuff is handy.  And actual MLS is barely on the
> radar here...)

strict policy was merged into targeted policy in F8, which paved the way
for actual user roles in F9.  You can get 95% of the behavior of strict
policy these days just by mapping Linux users to confined SELinux users
using semanage or system-config-selinux, or 100% of its behavior by
removing the unconfined module using semodule (but that's a destructive
operation that requires doing it in permissive and rebooting your system
since you'll invalidate all running processes in unconfined_t).

-- 
Stephen Smalley
National Security Agency


--
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 drafts: "Working with SELinux" sections

[Murray McAllister]

Valdis.Kletnieks@vt.edu wrote:
> On Tue, 23 Sep 2008 16:16:00 +1000, Murray McAllister said:
> 
>> * selinux-policy-[policy]: provides SELinux policies. For targeted 
>> policy, install selinux-policy-targeted. For MLS, install 
>> selinux-policy-mls. The strict policy was merged in Fedora 9, allowing 
>> confined and unconfined users to co-exist on the same system.
> 
> Strict was merged with what, exactly? (This threw me for a loop when
> strict evaporated out of rawhide, before I figured out that MLS was what
> I needed as the replacement - for most of my boxes, I don't actually *need*
> the MLS/MCS stuff, I just need to not have an 'unconfined' on the box.  For
> a *few* others, the MCS stuff is handy.  And actual MLS is barely on the
> radar here...)
Stephen answered this. I will try to cover it later.
> 
>> denied if running in enforcing mode. When using disabled mode, SELinux 
>> is disabled (the SELinux module is not registered with the Linux 
>> kernel), and only DAC rules are used.
> 
> Might want to note that operating in disabled mode probably means you want
> to do a relabel if you re-enable SELinux, because any files created/modified
> while running disabled are probably unlabeled.
I added a note. How about:

When systems run with SELinux in permissive or disabled mode, users have 
permission to label files incorrectly. Also, files created while SELinux 
is disabled are not labeled. This causes problems when changing to 
enforcing mode. To prevent incorrectly labeled and unlabeled files from 
causing problems, relabel the entire file system before enabling SELinux 
in enforcing mode.
> 
>> SELINUXTYPE=targeted: The SELINUXTYPE option sets the SELinux policy to 
>> use. Targeted policy is the default policy used. Only change this option 
>> if you want to use the MLS policy. To use the MLS policy, install the 
>> selinux-policy-mls package; configure SELINUXTYPE=mls in 
>> /etc/selinux/config; and reboot your system.
> 
> Someplace, you want to discuss why one might want to use MLS (whether as the
> replacement for the old 'strict' policy where everything ran confined as
> opposed to 'targeted', or if you have an actual use case for the MLS/MCS
> features).
I will try to cover this later, thanks.
> 
>> 4. In permissive mode, SELinux policy is not enforced, but denials are 
>> still logged for actions that would have been denied if running in 
>> enforcing mode. Before changing to enforcing mode, as the Linux root 
>> user, run the grep "SELinux is preventing" /var/log/messages command to 
> 
> Erm. What *exactly* produces that entry in /var/log/messages?
Are you referring to SELinux denying access or setroubelshoot-server?
   All my
> AVC stuff ends up in auditd.  Or is this just because the setroubleshoot
> RPMs aren't *quite* as mandatory as you noted above, and I don't see those
> messages because I don't have them installed *and enabled*? (Gotta watch
> out for those pesky 'chkconfig off' ;)
I thought I tried this before writing (thinking it only went into 
audit.log if setroubleshoot-server was installed, otherwise it would go 
to /var/log/messages). I will fix the text up to reflect this...

I will put a note about starting setroubleshoot after installing 
setroublehsoot-server (and checking chkconfig). I wanted them installed 
(not mandatory as you pointed out), because I thought, to start with, that:

Oct  1 20:04:57 localhost setroubleshoot: SELinux is preventing httpd 
(httpd_t) "getattr" to /var/www/html/file1 (samba_share_t). For complete 
SELinux messages. run sealert -l de7e30d6-5488-466d-a606-92c9f40d316d

Would be less intimidating than:

type=AVC msg=audit(1222855496.948:70): avc:  denied  { getattr } for 
pid=2120 comm="httpd" path="/var/www/html/file1" dev=dm-0 ino=399185 
scontext=unconfined_u:system_r:httpd_t:s0 
tcontext=system_u:object_r:samba_share_t:s0 tclass=file

> 
>> # should users run something like "> /var/log/messages" before rebooting?
> 
> This is a good way to lose potentially important log entries.  
Would running "ausearch -m avc -ts today" after relabeling be better?
Also,
> note that if the box is running syslog-ng, the file might be called
> /var/log/messages.YYMMDD or similar (very handy, that - no need to worry
> about cronjobs rolling the files).
I have not used that. Cheers for the tip :)
> 
>> 5. If there were no denial messages in /var/log/messages, configure 
>> SELINUX=enforcing in /etc/selinux/config:
> 
> You need to discuss the very possible case that there *were* denial messages.
> How do you fix them?  audit2allow is *one* option, as is correctly labelling
> files (if you have them in a non-standard place, you probably want to be doing
> an 'semanage fcontext -a').  But blindly doing either of those is a good way to
> hose yourself gloriously.
There is going to be a troubleshooting section that can be cross 
referenced here.

I do not know what sort of denials are common after relabeling, or how 
they can be fixed if the relabel process does not fix them. Does anyone 
know if it is common to have problems after relabeling?
> 
>> 7. As the Linux root user, run the semanage login -l command to confirm 
>> that the mapping between SELinux and Linux users is correct. The output 
>> should be as follows:
> 
> Also handy at this point - explain how to add additional SELinux userids
> and map login IDs to them (you can't really do anything with the MLS/MCS
> support if everybody is either user_u or staff_u).
This is coming next in a separate chapter. Why can't you do much with 
MCS if everyone is user_u? Doesn't it use the level, not the user/role/type?

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 drafts: "Working with SELinux" sections

[Valdis.Kletnieks]

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

On Wed, 01 Oct 2008 10:19:15 +1000, Murray McAllister said:

> > Erm. What *exactly* produces that entry in /var/log/messages?
> Are you referring to SELinux denying access or setroubelshoot-server?
> > AVC stuff ends up in auditd.  Or is this just because the setroubleshoot
> > RPMs aren't *quite* as mandatory as you noted above, and I don't see those
> > messages because I don't have them installed *and enabled*? (Gotta watch
> > out for those pesky 'chkconfig off' ;)
> I thought I tried this before writing (thinking it only went into 
> audit.log if setroubleshoot-server was installed, otherwise it would go 
> to /var/log/messages). I will fix the text up to reflect this...

AVC's go into dmesg (and wherever your syslog dumps that) if auditd isn't running.

AVC's goes into audit.log if auditd *is* running.

If setroubleshoot is running, it reads audit.log and pretty-prints them
into the syslog.

> This is coming next in a separate chapter. Why can't you do much with 
> MCS if everyone is user_u? Doesn't it use the level, not the user/role/type?

Whether you're using either the level or the classification, you need to be
able to run users at different levels/classes for it to do any real good:

Consider:

User1 can read classes A, B, C.
User2 can read classes B, D, E.
User3 can read classes A, B, and E.

Wow.  That works pretty nice.

Now consider if you only have 1 defined user for people to run as:

User_u can read classes A, B, C.
User_u can read classes B, D, E.
User_u can read.. oh nevermind. ;)

So you need to be able to say "userid fred runs as user1, userid joe runs
as user2, userid dept-paperwork runs as user3/levelA, userid dept-admin runs
as user3/levelB", and so on....

The stock MCS policy provides enough user classes and levels to protect the
*system* from users - but you need to roll-your-own to protect user data to
a similar level.


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: user guide drafts: "Working with SELinux" sections

[Murray McAllister]

Valdis.Kletnieks@vt.edu wrote:
> On Wed, 01 Oct 2008 10:19:15 +1000, Murray McAllister said:
> 
>>> Erm. What *exactly* produces that entry in /var/log/messages?
>> Are you referring to SELinux denying access or setroubelshoot-server?
>>> AVC stuff ends up in auditd.  Or is this just because the setroubleshoot
>>> RPMs aren't *quite* as mandatory as you noted above, and I don't see those
>>> messages because I don't have them installed *and enabled*? (Gotta watch
>>> out for those pesky 'chkconfig off' ;)
>> I thought I tried this before writing (thinking it only went into 
>> audit.log if setroubleshoot-server was installed, otherwise it would go 
>> to /var/log/messages). I will fix the text up to reflect this...
> 
> AVC's go into dmesg (and wherever your syslog dumps that) if auditd isn't running.
> 
> AVC's goes into audit.log if auditd *is* running.
> 
> If setroubleshoot is running, it reads audit.log and pretty-prints them
> into the syslog.
I added a small section:

Which Log File is Used

In Fedora 10, the setroubleshoot-server and audit packages are installed 
by default. These packages include the setroubleshootd and auditd 
daemons respectively. These daemons run by default.

SELinux denial messages, such as the following, are written to 
/var/log/audit/audit.log by default:

[example message]

Also, if setroubleshootd is running, which is it by default, denial 
messages from /var/log/audit/audit.log are translated to an 
easier-to-read form and sent to /var/log/messages:

[example message]

Denial messages are sent to a different location, depending on which 
daemons are running:

[segmented list]
Daemon		Log Location

auditd running		/var/log/audit/audit.log
auditd off; rsyslogd running	/var/log/messages
setroubleshootd		/var/log/audit/audit.log. Easier-to-read denial 
messages also sent to /var/log/messages

Sorry for how the table looks :(
> 
>> This is coming next in a separate chapter. Why can't you do much with 
>> MCS if everyone is user_u? Doesn't it use the level, not the user/role/type?
> 
> Whether you're using either the level or the classification, you need to be
> able to run users at different levels/classes for it to do any real good:
> 
> Consider:
> 
> User1 can read classes A, B, C.
> User2 can read classes B, D, E.
> User3 can read classes A, B, and E.
> 
> Wow.  That works pretty nice.
> 
> Now consider if you only have 1 defined user for people to run as:
> 
> User_u can read classes A, B, C.
> User_u can read classes B, D, E.
> User_u can read.. oh nevermind. ;)
> 
> So you need to be able to say "userid fred runs as user1, userid joe runs
> as user2, userid dept-paperwork runs as user3/levelA, userid dept-admin runs
> as user3/levelB", and so on....
> 
> The stock MCS policy provides enough user classes and levels to protect the
> *system* from users - but you need to roll-your-own to protect user data to
> a similar level.
> 


--
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 drafts: "Working with SELinux" sections

[Clarkson, Mike R (US SSA)]

> -----Original Message-----
> From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov]
On
> Behalf Of Valdis.Kletnieks@vt.edu
> Sent: Tuesday, September 30, 2008 9:00 PM
> To: Murray McAllister
> Cc: SE Linux
> Subject: Re: user guide drafts: "Working with SELinux" sections
> 
> On Wed, 01 Oct 2008 10:19:15 +1000, Murray McAllister said:
> 
> > > Erm. What *exactly* produces that entry in /var/log/messages?
> > Are you referring to SELinux denying access or
setroubelshoot-server?
> > > AVC stuff ends up in auditd.  Or is this just because the
> setroubleshoot
> > > RPMs aren't *quite* as mandatory as you noted above, and I don't
see
> those
> > > messages because I don't have them installed *and enabled*? (Gotta
> watch
> > > out for those pesky 'chkconfig off' ;)
> > I thought I tried this before writing (thinking it only went into
> > audit.log if setroubleshoot-server was installed, otherwise it would
go
> > to /var/log/messages). I will fix the text up to reflect this...
> 
> AVC's go into dmesg (and wherever your syslog dumps that) if auditd
isn't
> running.
> 
> AVC's goes into audit.log if auditd *is* running.
> 
> If setroubleshoot is running, it reads audit.log and pretty-prints
them
> into the syslog.
> 
> > This is coming next in a separate chapter. Why can't you do much
with
> > MCS if everyone is user_u? Doesn't it use the level, not the
> user/role/type?
> 
> Whether you're using either the level or the classification, you need
to
> be
> able to run users at different levels/classes for it to do any real
good:
> 
> Consider:
> 
> User1 can read classes A, B, C.
> User2 can read classes B, D, E.
> User3 can read classes A, B, and E.
> 
> Wow.  That works pretty nice.
> 
> Now consider if you only have 1 defined user for people to run as:
> 
> User_u can read classes A, B, C.
> User_u can read classes B, D, E.
> User_u can read.. oh nevermind. ;)
> 
> So you need to be able to say "userid fred runs as user1, userid joe
runs
> as user2, userid dept-paperwork runs as user3/levelA, userid
dept-admin
> runs
> as user3/levelB", and so on....
> 
> The stock MCS policy provides enough user classes and levels to
protect
> the
> *system* from users - but you need to roll-your-own to protect user
data
> to
> a similar level.

Even with all users mapped to selinux user user_u, mcs should still be
able to be used effectively. While it is true that in the case above,
user_u would need to be given access to all the compartments (A - E),
that does not mean that individual linux users (as opposed to the
selinux user user_u) must have access to all the compartments.
Individual linux users can be given access to only a subset of the
compartments through the "semanange login ..." command. The compartments
that individual linux users have access to can be seen using "semanage
login -l", and can be set by either adding or modifying a user with
"semanage login ...". For example:

semanage login -a -s user_u -r A joe

gives the linux user joe, access only to compartment A, even though his
linux user maps to the selinux user user_u, which has access to
compartments A-E



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