selinux from user POV

selinux from user POV

[Joshua Brindle]

This is going to be contraversial, I know, but this is something that
is fairly important to me and others I know of on this list.

Being a user on an SELinux machine is currently not good.. Ideally
it should be totally transparent but there are some issues. Mainly, 
right now, a user can't even add a .ssh directory and put their
ssh key in authorized_keys2 and then log in with it without the 
admin having to relabel (or at least label those objects) . 

Also, user webpages can't be read by apache until they are
labeled correctly, which makes them fairly useless. Users
can label  httpd_user_*_t but that clearly isn't something that 
most users are going to be aware of or desire to be hassled with.

There are a few solutions, many I don't like, the others I know
the nsa guys probably won't like but this is, like I said, fairly important.

1.An admin could cron relabeling to the /home partition, this is hackish
and doesn't seem like a good solution to me..

2. Could give users access to a limited setfiles script with a limited 
read-only file_contexts file that they can use on their own directories,
they'd also have to be given permission to label ssh types.. (ick)
it would also require additional user knowledge.. users aren't prone
to learn _anything_

--- nsa guys really won't like these---

3. Trap file creation in glibc and use a limited file_contexts that
glibc can read and setfscreatecon just before opening it for 
creation. This suffers from being in the context of whatever 
called for the file creation so many domains would possibly have
to be given relabel permissions. 

4. (This one may be over complicated but seems like the most
transparent solution). Load the file_contexts file into the kernel, 
NOT for enforcement of labels for files that already exist but
only for creation of new files. hook around open file, if it's being
created assign it's label, the file_contexts loaded into the kernel
could be limited to avoid any possible security hazards, this would
eliminate the need to assign relabeling permissions to user contexts
and application contexts that may need to create files in the user
home dirs.. (mail daemons, etc). 

#4 is my favorite but I don't know how complicated it could be
to implement, and I'm almost certain that the nsa guys will smite
me for this :( . It is the most transparent for the users, requires
the least work for the admin, and would really make selinux more
enterprise friendly.. 

Please give comments, flames, opinions, etc

Joshua Brindle




--
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: selinux from user POV

[Russell Coker]

On Sun, 12 Oct 2003 04:29, Joshua Brindle wrote:
> Being a user on an SELinux machine is currently not good.. Ideally
> it should be totally transparent but there are some issues. Mainly,
> right now, a user can't even add a .ssh directory and put their
> ssh key in authorized_keys2 and then log in with it without the
> admin having to relabel (or at least label those objects) .

One thing that should be noted at this time is that the problem is not just 
creation, it's also renaming.

For example if I keep a ~/www.bak directory that I can rename into place if a 
new change breaks something then I will want to permit Apache to serve 
content from it.

> Also, user webpages can't be read by apache until they are
> labeled correctly, which makes them fairly useless. Users
> can label  httpd_user_*_t but that clearly isn't something that
> most users are going to be aware of or desire to be hassled with.

This can of course be a configuration issue.  The administrator can decide 
whether to just grant apache access to the web content type or all files in 
the users' home directories.

> 1.An admin could cron relabeling to the /home partition, this is hackish
> and doesn't seem like a good solution to me..

You have to be really careful about hard links for this.  Of course if the 
relabel command would open the file first, get the current context, and then 
only make limited changes to it (EG preserving the identity and only making 
type changes within the range of types that a particular role has access to).

> 2. Could give users access to a limited setfiles script with a limited
> read-only file_contexts file that they can use on their own directories,

Why make it read-only?  If they want to copy the file_contexts file and make 
changes then it's their issue.

> they'd also have to be given permission to label ssh types.. (ick)

That shouldn't be a problem.  As they have full read-write access to the ssh 
types they can always achieve the same result by copying files around.  We 
should probably just grant that access.

> --- nsa guys really won't like these---
>
> 3. Trap file creation in glibc and use a limited file_contexts that
> glibc can read and setfscreatecon just before opening it for
> creation. This suffers from being in the context of whatever
> called for the file creation so many domains would possibly have
> to be given relabel permissions.

That also fails in the case of "mv".

mkdir ~/www.new
cd ~/www.new
tar xvzf /tmp/new-web-space.tgz
rm -rf ~/www
mv ~/www.new ~/www

Now my home page does not work...

> 4. (This one may be over complicated but seems like the most
> transparent solution). Load the file_contexts file into the kernel,
> NOT for enforcement of labels for files that already exist but
> only for creation of new files. hook around open file, if it's being

Loading regular expressions code into the kernel is not a good option.  But 
extending genfs_contexts to support basic wild-cards may be an option.

genfscon homefs /*/.gnupg       system_u:object_r:user_gpg_secret_t
genfscon homefs /*/.ssh         system_u:object_r:user_home_ssh_t

The problem is how to distinguish an ext3 file system used for /home from one 
used for /.  Maybe a mount option?  Maybe cat something to /selinux/
mount_context before mounting a file system?

I can't imagine any way of addressing this that isn't ugly.

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


--
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: selinux from user POV

[Brian May]

(note: my connection has been down, and mail is only just starting
to come it; I don't know if anyone else has replied yet, but I will
bite anyway).

On Sat, Oct 11, 2003 at 01:29:07PM -0500, Joshua Brindle wrote:
> 1.An admin could cron relabeling to the /home partition, this is hackish
> and doesn't seem like a good solution to me..
> 
> 2. Could give users access to a limited setfiles script with a limited 
> read-only file_contexts file that they can use on their own directories,
> they'd also have to be given permission to label ssh types.. (ick)
> it would also require additional user knowledge.. users aren't prone
> to learn _anything_
> 
> --- nsa guys really won't like these---
> 
> 3. Trap file creation in glibc and use a limited file_contexts that
> glibc can read and setfscreatecon just before opening it for 
> creation. This suffers from being in the context of whatever 
> called for the file creation so many domains would possibly have
> to be given relabel permissions. 

This would not work without spawning a seperate process to do
the relabeling.

> 4. (This one may be over complicated but seems like the most
> transparent solution). Load the file_contexts file into the kernel, 
> NOT for enforcement of labels for files that already exist but
> only for creation of new files. hook around open file, if it's being
> created assign it's label, the file_contexts loaded into the kernel
> could be limited to avoid any possible security hazards, this would
> eliminate the need to assign relabeling permissions to user contexts
> and application contexts that may need to create files in the user
> home dirs.. (mail daemons, etc). 

This would mean moving policy type decisions into the kernel.
IMHO we should be removing as much as possible from the kernel,
not adding to it.

Maybe, I guess the kernel could invoke a user level process when a
directory is created (hmmm... Sounds a bit like the Dazuko kernel patch
or possibly fam could be used), but I am not sure I like this approach.

My preference is a user level solution.

First off, why is this an issue in this first place?

Answer: because users home directories have already been created
without adding the these directories or setting the SE-Linux types.

Suggestion(1): would it be better if adduser and/or useradd was modified
to allow hooks to do this automatically?

Obviously this isn't going to work for existing users.

Suggestion(2). Use script/program, as in (1) that any user can run that
will automatically setup all(?) their directories to use defaults?
-- 
Brian May <bam@snoopy.apana.org.au>

--
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: selinux from user POV

[Brian May]

On Sun, Oct 12, 2003 at 01:09:27PM +1000, Russell Coker wrote:
> > 2. Could give users access to a limited setfiles script with a limited
> > read-only file_contexts file that they can use on their own directories,
> 
> Why make it read-only?  If they want to copy the file_contexts file and make 
> changes then it's their issue.

... because for the general case, a user could assign any file to any
type, and violate the system security policy (eg. a paranoid(?) security
policy might include something along the lines of "users must not be
allowed to view/execute files downloaded with Mozilla until after they
are scanned with a virus scanner; this wouldn't work if users had full
control over their file types).
-- 
Brian May <bam@snoopy.apana.org.au>

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

How to get Xfree86 to run - old API

[Michael Reilly]

When trying to run the Xfree86 server using startx as michaelr:sysadm_r:sysadm_t

the server does not startup.  This message is displayed

Fatal server error:
xf86OpenConsole: Cannot open /dev/tty0 (No such file or directory)

Looking at /dev/tty0

ls --context /dev/tty0
crw-------  michaelr staff    system_u:object_r:tty_device_t   /dev/tty0

And the server -

ls --context /usr/X11R6/bin/X
lrwxrwxrwx  root     root     system_u:object_r:xserver_exec_t 
/usr/X11R6/bin/X -> XFree86

ls --context /usr/X11R6/bin/XFree86
-rws--x--x  root     bin      system_u:object_r:xserver_exec_t 
/usr/X11R6/bin/XFree86

Nothing is printed in syslog - no avc deneid nor anything else.

How can I determine what is wrong and fix it?  What should I look at next?

Thanks,

michael
-- 
---- ---- ----
Michael Reilly    michaelr@cisco.com
     Cisco Systems, Santa Cruz, CA


--
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: How to get Xfree86 to run - old API

[Russell Coker]

On Sun, 12 Oct 2003 16:55, Michael Reilly wrote:
> When trying to run the Xfree86 server using startx as
> michaelr:sysadm_r:sysadm_t

This is probably not something that is desirable.  startx often runs lots of 
things that shouldn't have full access to the system.

> the server does not startup.  This message is displayed
>
> Fatal server error:
> xf86OpenConsole: Cannot open /dev/tty0 (No such file or directory)

Do you have startx.te compiled into your policy?

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


--
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: selinux from user POV

[Russell Coker]

On Sun, 12 Oct 2003 15:27, Brian May wrote:
> On Sun, Oct 12, 2003 at 01:09:27PM +1000, Russell Coker wrote:
> > > 2. Could give users access to a limited setfiles script with a limited
> > > read-only file_contexts file that they can use on their own
> > > directories,
> >
> > Why make it read-only?  If they want to copy the file_contexts file and
> > make changes then it's their issue.
>
> ... because for the general case, a user could assign any file to any
> type, and violate the system security policy (eg. a paranoid(?) security
> policy might include something along the lines of "users must not be
> allowed to view/execute files downloaded with Mozilla until after they
> are scanned with a virus scanner; this wouldn't work if users had full
> control over their file types).

So we make the policy only allow relabelto/from operations as suits our 
security goals.  In the example you give if you allow relabel from the type 
Mozilla uses to the regular type then you will lose if you allow creation of 
arbitary files/directories under the home directory.  But if you don't allow 
creation of arbitary file names then you have a problem which can easily be 
solved by file_type_auto_trans().

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


--
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: How to get Xfree86 to run - old API

[Michael Reilly]

I first tried to run it as michaelr:staff_r:tstaff_t with the same results.

I have startx.te in my policy (although the file startx.te itself has 
nothing but comments in it).  I do see a couple of ifdef(`startx.te', ` in 
x_client_macros.te

The policy statements enabled by the ifdef are iincluded n policy.conf.

Why is nothing logged?

michael
Russell Coker wrote:
> On Sun, 12 Oct 2003 16:55, Michael Reilly wrote:
> 
>>When trying to run the Xfree86 server using startx as
>>michaelr:sysadm_r:sysadm_t
> 
> 
> This is probably not something that is desirable.  startx often runs lots of 
> things that shouldn't have full access to the system.
> 
> 
>>the server does not startup.  This message is displayed
>>
>>Fatal server error:
>>xf86OpenConsole: Cannot open /dev/tty0 (No such file or directory)
> 
> 
> Do you have startx.te compiled into your policy?
> 

-- 
---- ---- ----
Michael Reilly    michaelr@cisco.com
     Cisco Systems, Santa Cruz, CA


--
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: selinux from user POV

[Stephen Smalley]

On Sat, 2003-10-11 at 14:29, Joshua Brindle wrote:
> This is going to be contraversial, I know, but this is something that
> is fairly important to me and others I know of on this list.
> 
> Being a user on an SELinux machine is currently not good.. Ideally
> it should be totally transparent but there are some issues. Mainly, 
> right now, a user can't even add a .ssh directory and put their
> ssh key in authorized_keys2 and then log in with it without the 
> admin having to relabel (or at least label those objects) . 

Put an empty .ssh directory in the /etc/skel directory and assign it the
correct type there, and modify useradd to preserve types when copying
the skeleton directory for new accounts.  Then when a user creates files
in that directory, they will inherit the right type by default.  Also,
make sure that all programs that automatically create .ssh
subdirectories are run in a domain that has a file_type_auto_trans rule
to put them into the right type.  I think that this needs to be done for
ssh-keygen.

> Also, user webpages can't be read by apache until they are
> labeled correctly, which makes them fairly useless. Users
> can label  httpd_user_*_t but that clearly isn't something that 
> most users are going to be aware of or desire to be hassled with.

As above, put an empty public_html directory into the skeleton directory
and type it properly there, and have useradd preserve the type when it
is copied.  Then the user's files will be typed correctly by default.

> 1.An admin could cron relabeling to the /home partition, this is hackish
> and doesn't seem like a good solution to me..

I'd agree that this is not a good solution.  You don't want to blindly
clobber the existing types; some files may have been typed automatically
based on file_type_auto_trans rules, some files may have been typed
explicitly by security-aware applications or users.  Also, as Russell
noted, hard links are an issue, but SELinux does control the ability to
create a hard link to a file based on the file's context.

> 2. Could give users access to a limited setfiles script with a limited 
> read-only file_contexts file that they can use on their own directories,
> they'd also have to be given permission to label ssh types.. (ick)
> it would also require additional user knowledge.. users aren't prone
> to learn _anything_

The control is provided by the kernel-enforced access controls on
relabeling, not by the setfiles program or the file_contexts
configuration.

> --- nsa guys really won't like these---

Correct.

> 3. Trap file creation in glibc and use a limited file_contexts that
> glibc can read and setfscreatecon just before opening it for 
> creation. This suffers from being in the context of whatever 
> called for the file creation so many domains would possibly have
> to be given relabel permissions. 

Nit:  Not relabel permission.  Creating a file with a particular context
is not the same as relabeling a file to a particular context, and
different permissions are checked.

I'd agree that this is not a good solution.

> 4. (This one may be over complicated but seems like the most
> transparent solution). Load the file_contexts file into the kernel, 
> NOT for enforcement of labels for files that already exist but
> only for creation of new files. hook around open file, if it's being
> created assign it's label, the file_contexts loaded into the kernel
> could be limited to avoid any possible security hazards, this would
> eliminate the need to assign relabeling permissions to user contexts
> and application contexts that may need to create files in the user
> home dirs.. (mail daemons, etc). 
> 
> #4 is my favorite but I don't know how complicated it could be
> to implement, and I'm almost certain that the nsa guys will smite
> me for this :( . It is the most transparent for the users, requires
> the least work for the admin, and would really make selinux more
> enterprise friendly.. 

Pathname-based security considered harmful.

The kernel already provides a mechanism for transparently labeling new
files.  See file_type_auto_trans.  In cases where this is insufficient,
security awareness in the program is required.


-- 
Stephen Smalley <sds@epoch.ncsc.mil>
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: selinux from user POV

[Thorsten Kukuk]

On Tue, Oct 14, Stephen Smalley wrote:

> On Sat, 2003-10-11 at 14:29, Joshua Brindle wrote:
> > This is going to be contraversial, I know, but this is something that
> > is fairly important to me and others I know of on this list.
> > 
> > Being a user on an SELinux machine is currently not good.. Ideally
> > it should be totally transparent but there are some issues. Mainly, 
> > right now, a user can't even add a .ssh directory and put their
> > ssh key in authorized_keys2 and then log in with it without the 
> > admin having to relabel (or at least label those objects) . 
> 
> Put an empty .ssh directory in the /etc/skel directory and assign it the
> correct type there, and modify useradd to preserve types when copying
> the skeleton directory for new accounts.  Then when a user creates files

The useradd implementation from the next pwdutils release (2.3.96)
will preserve all extended attributes when copying /etc/skel, this
means ACLs and SELinux attributes.

  Thorsten

-- 
Thorsten Kukuk       http://www.suse.de/~kukuk/        kukuk@suse.de
SuSE Linux AG        Deutschherrnstr. 15-19        D-90429 Nuernberg
--------------------------------------------------------------------    
Key fingerprint = A368 676B 5E1B 3E46 CFCE  2D97 F8FD 4E23 56C6 FB4B

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