SELinux: home dir is symlink, httpd from files in home dir

[Nick Urbanik]

Dear Folks,

I'm totally new to SELinux, and am quite confused on a number of
points.

I took the plunge and enabled SELinux on this FC3 box.
Problem is with Apache.  I have symlinks pointing to my home
directory, and to the pub directory, publicly served by Apache.

$ ls -l /home/nicku /var/ftp/pub
lrwxrwxrwx  1 root root 12 Oct 26 14:36 /home/nicku -> ../opt/nicku
lrwxrwxrwx  1 root root 13 Oct 26 14:48 /var/ftp/pub -> ../../opt/pub

ls -Zd /opt/nicku /home/nicku
lrwxrwxrwx  root     root     system_u:object_r:default_t      /home/nicku ->
../opt/nicku
drwx-----x  nicku    nicku    system_u:object_r:user_home_dir_t /opt/nicku

I have three main questions:

1. How do I solve my problem about httpd access to
   /opt/nicku/work/teaching/ict/ossi securely?
2. Where should I put my modifications to the policy?
3. What attribute should I give to the symlink /home/nicku?

Here is what I did:

After enabling SELinux, access to http://localhost/ossi was forbidden.

I then proceeded to try to make this work.  However, my fairly random
messing about is certainly not right.  I don't know where I should put
my modifications.  I would prefer not to change the original policy
files, but would prefer to make new ones.

Contents of
/etc/selinux/targeted/src/policy/file_contexts/misc/nicks-opt.fc:

/opt/lost\+found(/.*)?  system_u:object_r:lost_found_t
/opt/nicku      -d      system_u:object_r:user_home_dir_t
/opt/nicku/.+           system_u:object_r:user_home_t
/opt/ogg(/.*)?                system_u:object_r:default_t
/opt/pub(/.*)?                system_u:object_r:default_t
/opt/nicku/public_htm(/.*)?  system_u:object_r:httpd_user_content_t
/opt/backup(/.*)?             system_u:object_r:default_t
/opt/cdimage(/.*)?            system_u:object_r:default_t
/opt/nicku/photos(/.*)?         system_u:object_r:httpd_user_content_t
/opt/nicku/work/teaching/ict/snm(/.*)?  system_u:object_r:httpd_user_content_t
/opt/nicku/work/teaching/ict/ossi(/.*)? system_u:object_r:httpd_user_content_t

THIS IS CERTAINLY IN THE WRONG PLACE?  WHERE SHOULD IT GO?

cat /etc/selinux/targeted/src/policy/domains/program/apache-nicks-opt-extra.te
# Extra stuff for apache to cope with the symbolic links to
# /opt/nicku and /opt/pub

These came from audit2allow.  The first one is certainly wrong.  I
should change the attribute on the symlink /home/nicku.  What should I
change it to?

# to give access to /home/nicku:
# This looks BAD by removing SELinux protection of all symlinks:
allow httpd_t default_t:lnk_file { getattr read };

# to give access to /opt/pub:
allow httpd_t var_t:lnk_file { getattr read };

# to give access to /opt/nicku/{photos,work/{ossi,snm}}
allow httpd_t user_home_t:lnk_file { getattr read };

make reload complained till I touched this file:

ls -l /etc/selinux/targeted/src/policy/file_contexts/program/apache-nicks-opt-extra.fc
-rw-r--r--  1 root root 0 Jan 20 07:51
/etc/selinux/targeted/src/policy/file_contexts/program/apache-nicks-opt-extra.fc

From httpd configuration:

Alias /ossi /home/nicku/work/teaching/ict/ossi

<Location "/ossi">
    Options Indexes MultiViews FollowSymLinks
    AllowOverride None
    Order allow,deny
    Allow from all
</Location>

What should I do to enable httpd access to /ossi?

Here's what SELinux says:

Jan 20 10:53:20 nicku kernel: audit(1106178800.510:0): avc:  denied  { search } for 
pid=6133 exe=/usr/sbin/httpd name=work dev=sda1 ino=5620038
scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:user_home_t tclass=dir
Jan 20 10:53:20 nicku kernel: audit(1106178800.510:0): avc:  denied  { getattr } for 
pid=6133 exe=/usr/sbin/httpd path=/opt/nicku/work dev=sda1 ino=5620038
scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:user_home_t tclass=dir

When I do:

tail -20 /var/log/messages | audit2allow -v -i -
allow httpd_t user_home_t:dir { getattr search };
        #EXE=/usr/sbin/httpd  NAME=work   :  search
        #EXE=/usr/sbin/httpd  PATH=/opt/nicku/work   :  getattr

Where should this rule go?

I would prefer not to modify the installed
/etc/selinux/targeted/src/policy/domains/program/apache.te and
/etc/selinux/targeted/src/policy/file_contexts/program/apache.fc; I
would rather put my own customised changes in their own files so
updates to the policies can be easily installed.
-- 
Nick Urbanik   RHCE       http://nicku.org          nicku(at)nicku.org
Proud ex-member of Dept. of Information & Communications Technology in
Hong Kong IVE (Tsing Yi), Home of Visual Paradigm: Jolt Productivity
Award winner, programmed by ICT's own graduates!
GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24    ID: BB9D2C24

[Colin Walters]

On Thu, 2005-01-20 at 11:23 +1100, Nick Urbanik wrote:
>  Dear Folks,
>  
>  I'm totally new to SELinux, and am quite confused on a number of
>  points.
>  
>  I took the plunge and enabled SELinux on this FC3 box.
>  Problem is with Apache.  
Have you read the Fedora Apache guide?

http://fedora.redhat.com/docs/selinux-apache-fc3/

It's slightly out of date but still informative, I think.

>   I have symlinks pointing to my home
>  directory, 
This will cause a number of problems.  Many programs are given the
permissions 'getattr' and 'search' on user_home_dir_t:dir, so they can
access the toplevel home directory but not necessarily anything
contained in it.  The ":dir" part here is important, as it means the
permissions are restricted to directories with that type; symlinks are
not allowed.

I wonder why you're symlinking into /opt, but assuming for now that's
what you have to do, one solution might be to use bind mounts instead of
symlinks:

rm /home/nicku
mkdir /home/nicku
mount -obind /opt/nicku /home/nicku

You can add the bind mount to /etc/fstab so it's done automatically.

Another (very hackish) approach might be to label the /home/nicku
symlink with a type such as usr_t; most domains have permission to read
usr_t:lnk_file (i.e. symlink).

That's about all I can think of, short of modifying the policy sources.

>  1. How do I solve my problem about httpd access to
>     /opt/nicku/work/teaching/ict/ossi securely? 
I hope the above helps.

>  2. Where should I put my modifications to the policy? 
If you choose to modify policy, the right solution I think is to label
the /home/nicku symlink with the type user_home_dir_t, and add the
permissions like:

allow <domain> user_home_dir_type:lnk_file { getattr read };

Substitute particular domains such as httpd_t for <domain>.

When I modify policy, I tend to put my modifications in a local.te file.

>  3. What attribute should I give to the symlink /home/nicku? 
user_home_dir_t.

>  /etc/selinux/targeted/src/policy/file_contexts/misc/nicks-opt.fc:
>  
>  /opt/lost\+found(/.*)?  system_u:object_r:lost_found_t
>  /opt/nicku      -d      system_u:object_r:user_home_dir_t
>  /opt/nicku/.+           system_u:object_r:user_home_t
>  /opt/ogg(/.*)?                system_u:object_r:default_t
>  /opt/pub(/.*)?                system_u:object_r:default_t 
Hmm; using the default_t type seems a bit wrong, but I can't think
offhand of something better.

>  /opt/nicku/public_htm(/.*)?  system_u:object_r:httpd_user_content_t
Right.

>  THIS IS CERTAINLY IN THE WRONG PLACE?  WHERE SHOULD IT GO? 
No, that's fine.

>  cat
> /etc/selinux/targeted/src/policy/domains/program/apache-nicks-opt-extra.te 
Reasonable, although I like using a well-commented local.te personally.

>  # to give access to /home/nicku:
>  # This looks BAD by removing SELinux protection of all symlinks:
>  allow httpd_t default_t:lnk_file { getattr read }; 
It doesn't remove protection of all symlinks, but it does mean that
Apache can read symlinks that aren't assigned a label by the
file_contexts regexps (i.e. are given the default_t type).  Given that
you're using default_t for a lot of data, I wouldn't recommend this
permission.

>  # to give access to /opt/pub:
>  allow httpd_t var_t:lnk_file { getattr read }; 
I'd use bind mounts instead of permissions like this, personally.  But
this one probably isn't too harmful.

>  # to give access to /opt/nicku/{photos,work/{ossi,snm}}
>  allow httpd_t user_home_t:lnk_file { getattr read }; 
This is bad; the data should be labeled as httpd_user_content_t.

>  make reload complained till I touched this file:
>  
>  ls -l /etc/selinux/targeted/src/policy/file_contexts/program/apache-nicks-opt-extra.fc
>  -rw-r--r--  1 root root 0 Jan 20 07:51
>  /etc/selinux/targeted/src/policy/file_contexts/program/apache-nicks-opt-extra.fc 
Yeah; use misc/local.te instead, or the like.  te files in program
require a corresponding .fc file to be enabled.

>  What should I do to enable httpd access to /ossi?
>  
>  Here's what SELinux says:
>  
>  Jan 20 10:53:20 nicku kernel: audit(1106178800.510:0): avc:  denied  { search } for 
> pid=6133 exe=/usr/sbin/httpd name=work dev=sda1 ino=5620038
> scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:user_home_t tclass=dir
>  Jan 20 10:53:20 nicku kernel: audit(1106178800.510:0): avc:  denied  { getattr } for 
> pid=6133 exe=/usr/sbin/httpd path=/opt/nicku/work dev=sda1 ino=5620038
> scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:user_home_t tclass=dir 
Any data you want httpd to access needs to be one of the types outlined
in the Fedora Apache/SELinux guide, such as httpd_user_content_t.

[Nick Urbanik]

Thank you very much for your very helpful reply, Colin.

On Wed, Jan 19, 2005 at 09:48:30PM -0500, Colin Walters wrote:
>  On Thu, 2005-01-20 at 11:23 +1100, Nick Urbanik wrote:
>  > Dear Folks,
>  > 
>  > I'm totally new to SELinux, and am quite confused on a number of
>  > points.
>  > 
>  > I took the plunge and enabled SELinux on this FC3 box.
>  > Problem is with Apache. 
>  
>  Have you read the Fedora Apache guide? 
Thank you, yes, it is very helpful.

>  http://fedora.redhat.com/docs/selinux-apache-fc3/
>  
>  It's slightly out of date but still informative, I think. 
Thanks.  I have finally got everything to work, and now will make it
work more securely.

>  >  I have symlinks pointing to my home
>  > directory,
>  
>  This will cause a number of problems.  Many programs are given the
>  permissions 'getattr' and 'search' on user_home_dir_t:dir, so they can
>  access the toplevel home directory but not necessarily anything
>  contained in it.  The ":dir" part here is important, as it means the
>  permissions are restricted to directories with that type; symlinks are
>  not allowed.
>  
>  I wonder why you're symlinking into /opt, 
I have a 512 gigabyte 3ware raid partition, and am using it for many
different purposes, and had used symlinks to access it.  I'm changing
it to mount as you sensibly suggest.

>  but assuming for now that's what you have to do, one solution
> might
>  be to use bind mounts instead of symlinks:
>  
>  rm /home/nicku
>  mkdir /home/nicku
>  mount -obind /opt/nicku /home/nicku
>  
>  You can add the bind mount to /etc/fstab so it's done automatically. 
That's a wonderful idea!  The mount man page indicates that I can use

mount --move /opt/nicku /home/nicku

to achieve exactly what I wanted originally.  Does that work well?

>  Yeah; use misc/local.te instead, or the like.  te files in program
>  require a corresponding .fc file to be enabled. 
Yes, I finally realised that's where it should go.
-- 
Nick Urbanik   RHCE       http://nicku.org          nicku(at)nicku.org
Proud ex-member of Dept. of Information & Communications Technology in
Hong Kong IVE (Tsing Yi), Home of Visual Paradigm: Jolt Productivity
Award winner, programmed by ICT's own graduates!
GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24    ID: BB9D2C24

[Colin Walters]

On Thu, 2005-01-20 at 14:44 +1100, Nick Urbanik wrote:

>  I have a 512 gigabyte 3ware raid partition, and am using it for many
>  different purposes, and had used symlinks to access it.  I'm changing
>  it to mount as you sensibly suggest. 
You could use LVM to pool your local disk containing / and the raid
partition containing /opt; this makes the fact that the files are on
different stores transparent to applications and removes the need for
symlinks or bind mounts, and in general is a lot nicer to manage.

>  That's a wonderful idea!  The mount man page indicates that I can
> use
>  
>  mount --move /opt/nicku /home/nicku 
Ah, it's unclear to me exactly what --move is supposed to do; the
example doesn't work for me.

(OT) LVM and mount (was SELinux: home dir is symlink, httpd from files in home dir)

[Nick Urbanik]

G'day,

On Wed, Jan 19, 2005 at 10:56:16PM -0500, Colin Walters wrote:
>  On Thu, 2005-01-20 at 14:44 +1100, Nick Urbanik wrote:
>  
>  > I have a 512 gigabyte 3ware raid partition, and am using it for many
>  > different purposes, and had used symlinks to access it.  I'm changing
>  > it to mount as you sensibly suggest.
>  
>  You could use LVM to pool your local disk containing / and the raid
>  partition containing /opt; this makes the fact that the files are on
>  different stores transparent to applications and removes the need for
>  symlinks or bind mounts, and in general is a lot nicer to manage. 
Yes, I used LVM for many years, but found that the performance of the
virtual disks was quite a lot lower than the physical ones (using
hdparm -t and other measures).  That has probably changed by now; I
was using LVM 1.

>  > That's a wonderful idea!  The mount man page indicates that
> I can use
>  > 
>  > mount --move /opt/nicku /home/nicku
>  
>  Ah, it's unclear to me exactly what --move is supposed to do; the
>  example doesn't work for me. 
No, it didn't work for me either.  I used bind mounts, which do the
job just nicely.
-- 
Nick Urbanik   RHCE       http://nicku.org          nicku(at)nicku.org
Proud ex-member of Dept. of Information & Communications Technology in
Hong Kong IVE (Tsing Yi), Home of Visual Paradigm: Jolt Productivity
Award winner, programmed by ICT's own graduates!
GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24    ID: BB9D2C24

(OT) LVM and mount (was SELinux: home dir is symlink, httpd from files in home dir)

[Russell Coker]

On Thursday 20 January 2005 19:04, Nick Urbanik <nicku(a)nicku.org&gt; wrote:
>  Yes, I used LVM for many years, but found that the performance of
> the
>  virtual disks was quite a lot lower than the physical ones (using
>  hdparm -t and other measures).  That has probably changed by now; I
>  was using LVM 1. 
Everything has changed since LVM1.  Please run the benchmarks that matter to 
you using LVM2 with a recent Fedora or RHEL kernel.  If you find any 
significant performance loss then please raise it for discussion on 
fedora-devel-list or an LVM list.

LVM should be giving you good performance.

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