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 <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.
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
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.
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?
On Fri, 25 Jul 2008 21:54:51 +0000 (UTC) Mike mike.cloaked@gmail.com 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.
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@lists.fedoraproject.org