SELinux concerning /home symlink?

[mike cloaked]

I have had a thread running on Fedora list about a specific SELinux issue
I have hit with F9.

The history is that I did a clean install on a machine that was previously
running F8, keeping /opt as an untouched partition and installed F9,
leaving the SELinux enforcing on.

On that /opt partition I keep the user area as /opt/Local/home, and 
as previously after the install I do
cd /
mv home home.dist
ln -s /opt/Local/home .

This then previously set my home areas to the way they were - 

On the machine in question this worked fine initially until I tried
to ssh in to the machine from another in my local LAN.

I was only able to login but could not change directory to the user home
directory.

There was a sealert message in /var/log/messages which indicated that
I should restorecon -v /opt/* which I did - 

The contexts that are relevant were previously as follows:
[mike <at> lapmike2 mike]$ ls -Zd /opt/Local/home
drwxr-xr-x  root root system_u:object_r:file_t:s0      /opt/Local/home
[mike <at> lapmike2 mike]$ ls -Zd /home
lrwxrwxrwx  root root unconfined_u:object_r:root_t:s0  /home -> /opt/Local/home
[mike <at> lapmike2 mike]$ ls -Zd /home/mike
drwx------  mike mike system_u:object_r:user_home_dir_t:s0 /home/mike
[mike <at> lapmike2 mike]$ ls -Zd /opt/Local/home/mike
drwx------  mike mike system_u:object_r:user_home_dir_t:s0 /opt/Local/home/mike
[mike <at> lapmike2 mike]$ ls -Zd /home/mike/.bash_profile
-rw-r--r--  mike mike system_u:object_r:user_home_t:s0 /home/mike/.bash_profile

I noticed that my /opt/Local/home has a type file_t whereas
a posting in fedora list indicated it should be home_root_t 

I ran restorecon -v /opt/*
The context for /opt/Local/home then had a type usr_t
So I did
chcon -t home_root_t 

At this point I could login to the machine using ssh as user mike.
However I could not use passwordless ssh login even though I did have
the previously working ~/.ssh directory.

The sealert message suggested that the context of the authorized_keys2 file
was wrong and I should run 
restorecon -v /opt/Local/home/mike/.ssh/authorized_keys2
After doing this the context seemed the same as before and ssh remains
only with a password for access and no passwordless login was possible.

I found that another user reported a similar issue:
http://www.mjmwired.net/linux/2008/06/16/
selinux-preventing-ssh-passwordless-login/
(This url should be on a single line)

So how do I proceed?
Is the problem caused by the fact that the home area is symlinked from
/home to /opt/Local/home ?

I have seen some suggestion in a blog elsewhere that symlinks are 
problematic in SELinux?  Maybe I need to create a directory /home 
and then bind mount /opt/Local/home onto it?

Any advice would be appreciated as I am very new to SELinux, but would
like to make it work rather than switching it off as I have done up to now.

Thanks
Mike

[mike cloaked]

Mike <mike.cloaked <at> gmail.com> writes:

>  Is the problem caused by the fact that the home area is symlinked
> from
>  /home to /opt/Local/home ? 
It turned out that I have managed to fix the issue by changing the contexts
of the files in /opt/Local/home/mike/.ssh to type user_home_t - and now
the ssh problem has gone away.

I was told by a helpful poster in Fedora list that the fact that my home
areas are on /opt would have resulted in inappropriate contexts for 
/opt/Local/home since this would have been different if the partition had
been /home and not under /opt - this was indeed the case and changing
to user_home_t fixed this.

I therefore suspect that I should change all the contexts to the same type
in /opt/Local/home

Anyway problem solved for the moment... this kind of information may well
be useful to others who have atypical home areas for ease of doing upgrades.

[Craig White]

On Thu, 2008-07-24 at 21:41 +0000, Mike wrote:
>  Mike <mike.cloaked <at> gmail.com> writes:
>  
>  > Is the problem caused by the fact that the home area is symlinked from
>  > /home to /opt/Local/home ?
>  
>  It turned out that I have managed to fix the issue by changing the contexts
>  of the files in /opt/Local/home/mike/.ssh to type user_home_t - and now
>  the ssh problem has gone away.
>  
>  I was told by a helpful poster in Fedora list that the fact that my home
>  areas are on /opt would have resulted in inappropriate contexts for 
>  /opt/Local/home since this would have been different if the partition had
>  been /home and not under /opt - this was indeed the case and changing
>  to user_home_t fixed this.
>  
>  I therefore suspect that I should change all the contexts to the same type
>  in /opt/Local/home
>  
>  Anyway problem solved for the moment... this kind of information may well
>  be useful to others who have atypical home areas for ease of doing upgrades. 
----
I would suggest that you would be far better off mounting the partition
you now called /opt as /home and then move stuff around...

i.e.

init 1
umount /opt
# then edit /etc/fstab so whatever partition mounts at /opt mounts
at /home
mount /home
cd /home
mv Local/home/* .
# then mv everything that belongs in /opt to /opt
# then init 3/5

Craig

[Todd Zullinger]

Craig White wrote:
>  I would suggest that you would be far better off mounting the
>  partition you now called /opt as /home and then move stuff around... 
Or bind mount /home to /opt/Local/home and then run restorecon -R
/home to apply the proper labels to /home.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The downside of being better than everyone else is that people tend to
assume you're pretentious.
    -- Demotivators (www.despair.com)

[mike cloaked]

Todd Zullinger <tmz <at> pobox.com> writes:

>  Or bind mount /home to /opt/Local/home and then run restorecon -R
>  /home to apply the proper labels to /home. 
Thanks everyone - I will try bind mounting this evening....

Mike

[mike cloaked]

Mike <mike.cloaked <at> gmail.com> writes:

>  Thanks everyone - I will try bind mounting this evening.... 
I got the /home pointing to /opt/Local/home just fine - but ...now doing mail:

Having just been pretty pleased with myself for getting my system running
I now find a problem.... This question was also posted to Fedora list.

First I have my home directory bind mounted from /home to /opt/Local/home
with no problems, and I bind mount using an fstab entry like
/opt/Local/home   /home   ext3 bind 0 0 

The context for /home is system_u:object_r:home_root_t:s0
and for /opt/Local/home it is the same.

The mount works fine during boot - so I tried the same with my mail.

I have an fstab entry
/opt/Local/spool/mail /var/spool/mail   ext3 bind  0 0

The context for /var/spool/mail is system_u:object_r:mail_spool_t:s0
and for /opt/Local/spool/mail it is also the same.

I can manually do
mount /var/spool/mail  and the bind mount works fine.

However on boot I get an avc denial, with kernel: type=1400 and
and avc: denied {mounton} .... comm="mount" path="/var/spool/mail"
dev=sda5 ino=419655 scontext=system_u:system_r:mount_t:so 
tcontext=system_u:object_r:mail_spool_t:so class=dir

I am not sure what to change to make this work?

[Paul Howarth]

On Fri, 25 Jul 2008 21:54:51 +0000 (UTC)
Mike  <mike.cloaked(a)gmail.com&gt; wrote:

>  Mike <mike.cloaked <at> gmail.com> writes:
>  
>  > Thanks everyone - I will try bind mounting this evening....
>  
>  I got the /home pointing to /opt/Local/home just fine - but ...now
>  doing mail:
>  
>  Having just been pretty pleased with myself for getting my system
>  running I now find a problem.... This question was also posted to
>  Fedora list.
>  
>  First I have my home directory bind mounted from /home
>  to /opt/Local/home with no problems, and I bind mount using an fstab
>  entry like /opt/Local/home   /home   ext3 bind 0 0 
>  
>  The context for /home is system_u:object_r:home_root_t:s0
>  and for /opt/Local/home it is the same.
>  
>  The mount works fine during boot - so I tried the same with my mail.
>  
>  I have an fstab entry
>  /opt/Local/spool/mail /var/spool/mail   ext3 bind  0 0
>  
>  The context for /var/spool/mail is system_u:object_r:mail_spool_t:s0
>  and for /opt/Local/spool/mail it is also the same.
>  
>  I can manually do
>  mount /var/spool/mail  and the bind mount works fine.
>  
>  However on boot I get an avc denial, with kernel: type=1400 and
>  and avc: denied {mounton} .... comm="mount" path="/var/spool/mail"
>  dev=sda5 ino=419655 scontext=system_u:system_r:mount_t:so 
>  tcontext=system_u:object_r:mail_spool_t:so class=dir
>  
>  I am not sure what to change to make this work? 
First temporarily unmount the bind mount:
# umount /var/spool/mail

Then change the context of the original /var/spool/mail to make it
suitable for use as a mount point:
# chcon -t mnt_t /var/spool/mail

Mount at boot should now work. You can simulate this without actually
rebooting by doing:
# service netfs start

Cheers, Paul.

[mike cloaked]

Paul Howarth <paul <at> city-fan.org> writes:

temporarily unmount the bind mount:
>  # umount /var/spool/mail
>  
>  Then change the context of the original /var/spool/mail to make it
>  suitable for use as a mount point:
>  # chcon -t mnt_t /var/spool/mail
>  
>  Mount at boot should now work. You can simulate this without actually
>  rebooting by doing:
>  # service netfs start 
Thank you Paul

I'll do this later today when I get back to the machine....

Much appreciated
Mike

SELinux concerning /home symlink? - Resolved

[mike cloaked]

Mike <mike.cloaked <at> gmail.com> writes:

>  
>  Paul Howarth <paul <at> city-fan.org> writes: 
>  > # chcon -t mnt_t /var/spool/mail 
Excellent - this works just fine - many thanks for your help.