Some questions relating to selinux

[Gene Czarcinski]

The following is a mixed bag of comments/questions related to SElinux...

1. I noticed that when I login as root from a VT I get the choice of 3 
different roles (staff_r, sysadm_r, and system_r) but when I login as a 
sysadm_r user and then "su -" to root, I only get two roles (staff_r and 
sysadm_r).  Whe the difference?  Better still, is this intentional?

2. If I login a VT or su to a user who has multiple roles defined, I get the 
option to select which role (when su - is working).  On the other hand, if I 
login via gdm I do not get such a choice.  Question:  should gdm be enhanced 
to offer to option to select a role for users with multiple roles defined?

3. In the /etc/security/selinux/src/policy/users file there are two examples 
of defining a user having sysadm_r:

# sample for administrative user
#user jadmin roles { staff_r sysadm_r ifdef(`direct_sysadm_daemon', \ 
`system_r') };
 
# sample for regular user
#user jdoe roles { user_r ifdef(`user_canbe_sysadm', `sysadm_r system_r') };

Which one is the "right" one to use?

4.  In the above, I notice that if I login from gdm I get sysadm_r in the 
first case and user_r in the second case.  However, if I login from a VT, the 
default role is sysadm_r in both cases.  Is this operating correctly?  Why 
the difference?  It seems to me that the correct operation should be the same 
in both cases.

5.  Why is the system_r role only available from the VT?

6.  Is there some command that will list the roles available for a user?

7.  The packages libselinux has a lot of /usr/bin/ files which have no 
documentation (e.g., setfilecon).  Is there some reason for this (other than 
we have not got around to that yet)?

8.  Is there someplace that describes the differences between the various 
policy versions (15, 16, 17, etc.)?

9.  Is there some additional documentation concerning the 
/etc/security/selinux/src/policy/tunable.te file (besides the comments in the 
file itself)?  

10. Is there any documentation planned (but maybe not in FC2) which will make 
recommendations on how to lock a system down using the tunable.te file?

11. For the record, my "vote" is for FC2 final to default to selinux=1, 
enforcing=1 but with a policy that is very "loose" by default (it would more 
or less work as if selinux was not really installed for most users).  I would 
also like to see an option for a more restrictive policy which could then be 
worked with for those inclined to do so.

12. I noticed that if I login as a user defined in users as above case 2 and 
then "su -" to root, I am given no role options.  However, if I login as a 
sysadm_r user (case 1 above) and then "su -" to root, I am given a choice of 
role.  Why the difference?  If this operating correctly?
------------------------------------------------------------------------------------
I am sure that more questions will occur to me but that is enough for now.

Gene

[Russell Coker]

On Tue, 13 Apr 2004 00:44, Gene Czarcinski <gene(a)czarc.net&gt; wrote:
>  The following is a mixed bag of comments/questions related to
> SElinux...
>
>  1. I noticed that when I login as root from a VT I get the choice of 3
>  different roles (staff_r, sysadm_r, and system_r) but when I login as a
>  sysadm_r user and then "su -" to root, I only get two roles (staff_r and
>  sysadm_r).  Whe the difference?  Better still, is this intentional? 
The fact that you are offered system_r is a bug.  Being offered the other two 
is OK, but you can turn this off by removing the "multiple" option from 
pam_selinux.so in the pam.d file.

>  2. If I login a VT or su to a user who has multiple roles defined, I
> get
>  the option to select which role (when su - is working).  On the other hand,
>  if I login via gdm I do not get such a choice.  Question:  should gdm be
>  enhanced to offer to option to select a role for users with multiple roles
>  defined? 
We discussed this at length and came to the conclusion that running a GNOME or 
KDE environment in a privileged role is a bad idea.  Also GNOME and KDE 
create lots of /tmp entries such as /tmp/mcop-user and /tmp/.gconf-user.  If 
you login to GNOME or KDE as one role and then login as the same UID with 
another role then one of two things will happen:

1)  role A is not permitted to write to role B's /tmp files and the login will 
fail in ways that might be surprising and difficult to debug.

2)  role A is permitted to write to role B's /tmp files, things will work BUT 
role A can probably use this to take over role B processes.  If we permit 
this bi-directionally so that no combination of X login order will result in 
failure then we give role A and role B such access to each other that we 
should just merge them.

The conclusion is that there is no benefit in giving the user two roles and 
allowing them both to be accessed through a GUI login.

>  3. In the /etc/security/selinux/src/policy/users file there are two
>  examples of defining a user having sysadm_r:
>
>  # sample for administrative user
>  #user jadmin roles { staff_r sysadm_r ifdef(`direct_sysadm_daemon', \
>  `system_r') };
>
>  # sample for regular user
>  #user jdoe roles { user_r ifdef(`user_canbe_sysadm', `sysadm_r system_r')
>  };
>
>  Which one is the "right" one to use? 
jdoe is a regular user, jadmin is an administrative user.  Which one you use 
for an account depends on whether they are a regular user or an admin.

>  4.  In the above, I notice that if I login from gdm I get sysadm_r in
> the
>  first case and user_r in the second case.  However, if I login from a VT,
>  the default role is sysadm_r in both cases.  Is this operating correctly? 
>  Why the difference?  It seems to me that the correct operation should be
>  the same in both cases. 
See /etc/security/default_contexts .

>  5.  Why is the system_r role only available from the VT? 
The bug is limited in scope.

>  6.  Is there some command that will list the roles available for a
> user? 
The users file will contain the list, it should be possible to get the list 
from the kernel as well.

>  7.  The packages libselinux has a lot of /usr/bin/ files which have
> no
>  documentation (e.g., setfilecon).  Is there some reason for this (other
>  than we have not got around to that yet)? 
We haven't got around to it yet.  Contributions of man pages are welcome...

>  9.  Is there some additional documentation concerning the
>  /etc/security/selinux/src/policy/tunable.te file (besides the comments in
>  the file itself)? 
Not yet.

>  10. Is there any documentation planned (but maybe not in FC2) which
> will
>  make recommendations on how to lock a system down using the tunable.te
>  file? 
Yes, we will have to do that.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

[Colin Walters]

On Mon, 2004-04-12 at 13:06, Russell Coker wrote:

>  We discussed this at length and came to the conclusion that running a
> GNOME or 
>  KDE environment in a privileged role is a bad idea.   
The problem is that it's going to happen.  E.g. if you log in as a
staff_r, then inside a terminal use 'su' to become root/sysadm_r, and
run a program that uses X.

>  Also GNOME and KDE 
>  create lots of /tmp entries such as /tmp/mcop-user and /tmp/.gconf-user.  If 
>  you login to GNOME or KDE as one role and then login as the same UID with 
>  another role then one of two things will happen:
>  
>  1)  role A is not permitted to write to role B's /tmp files and the login will 
>  fail in ways that might be surprising and difficult to debug.
>  
>  2)  role A is permitted to write to role B's /tmp files, things will work BUT 
>  role A can probably use this to take over role B processes.  If we permit 
>  this bi-directionally so that no combination of X login order will result in 
>  failure then we give role A and role B such access to each other that we 
>  should just merge them. 
There's a third option - write policy such that only for those shared
files, each role can access the other's files.  That's what I'm working
on right now with GConf.

>  The conclusion is that there is no benefit in giving the user two
> roles and 
>  allowing them both to be accessed through a GUI login. 
Although we don't have SE-X yet, making most of this moot, I think it's
still a worthwhile goal.

[Gene Czarcinski]

On Monday 12 April 2004 13:06, Russell Coker wrote:
>  On Tue, 13 Apr 2004 00:44, Gene Czarcinski <gene(a)czarc.net&gt;
> wrote:
>  > The following is a mixed bag of comments/questions related to SElinux...
>  >
>  > 1. I noticed that when I login as root from a VT I get the choice of 3
>  > different roles (staff_r, sysadm_r, and system_r) but when I login as a
>  > sysadm_r user and then "su -" to root, I only get two roles (staff_r and
>  > sysadm_r).  Whe the difference?  Better still, is this intentional?
>
>  The fact that you are offered system_r is a bug.  Being offered the other
>  two is OK, but you can turn this off by removing the "multiple" option from
>  pam_selinux.so in the pam.d file. 
OK, I will file a bugzilla report against policy (unless you suggest something 
else).

[snip]
>  > 3. In the /etc/security/selinux/src/policy/users file there are
> two
>  > examples of defining a user having sysadm_r:
>  >
>  > # sample for administrative user
>  > #user jadmin roles { staff_r sysadm_r ifdef(`direct_sysadm_daemon', \
>  > `system_r') };
>  >
>  > # sample for regular user
>  > #user jdoe roles { user_r ifdef(`user_canbe_sysadm', `sysadm_r system_r')
>  > };
>  >
>  > Which one is the "right" one to use?
>
>  jdoe is a regular user, jadmin is an administrative user.  Which one you
>  use for an account depends on whether they are a regular user or an admin. 
I saw little difference in the capabilities.  When I login from gdm, the 
administrative user's role is sysadm_4.  When I login from gdm, the "regular 
user's" role is user_r but I can change to sysadm_r with the newrole command.  
The "role" I am seeing is the result of running "id -Z" in a terminal
window.  
As a regular user (e.g., jdoe), I can run things like system-config-users by 
entering jdoe's password ... the same thing I have to do when I login as the 
administrative user (e.g., jadmin).

I am also wonder what role is being used for most programs if I login as the 
adminstrative user.  Aren't these running with sysadm_r.  If so, it appears 
to me that the "safer" way is to use the"jdoe style" since it seems to

provide the same capabilities but defaults to user_r.

This leads to another question: just what capabilities does sysadm_r have if I 
am running it as the default?

Also, if I ssh in (as admin user for example), I get exactly the same role 
that I get when I login from gdm.

>  > 4.  In the above, I notice that if I login from gdm I get sysadm_r in the
>  > first case and user_r in the second case.  However, if I login from a VT,
>  > the default role is sysadm_r in both cases.  Is this operating correctly?
>  > Why the difference?  It seems to me that the correct operation should be
>  > the same in both cases.
>
>  See /etc/security/default_contexts . 
I am not sure I see what this means (the contents of the file that is).  The 
implication I see is that I should not be able to ssh in with sysadm_r but I 
do (see above).

[snip]
>  > 6.  Is there some command that will list the roles available for
> a user?
>
>  The users file will contain the list, it should be possible to get the list
>  from the kernel as well. 
And the command to display the roles is ...?

[snip]
>  > 10. Is there any documentation planned (but maybe not in FC2)
> which will
>  > make recommendations on how to lock a system down using the tunable.te
>  > file?
>
>  Yes, we will have to do that. 
This is going to be a must for a lot of individuals.  They will need to see 
hoiw to lock things down (and a bit of why) in order to see why seliniux is a 
good thing.  I also believe this needs to be rather cookbookish so that folks 
do not have to work too hard to get some benefit.  Otherwise a log of folks 
will be inclined to run selinux (witness the discussion on this list and 
others about what the default will be for FC2 final).

Gene

[James Morris]

On Mon, 12 Apr 2004, Gene Czarcinski wrote:

>  8.  Is there someplace that describes the differences between the
> various 
>  policy versions (15, 16, 17, etc.)? 
Version 16 added boolean policy support, and version 17 adds ipv6 support.

- James
-- 
James Morris
<jmorris(a)redhat.com&gt;