Re: SELinux, NIS, NFS, and /home, trouble with Fedora 18 converting user_home_dir_t to detault_t

[Roland Roberts]

For reasons I don't understand, the install labelled /home with (I think, I'm
offsite with no access) auto_fs_t as it is a mount point for autofs.

Roland
--
Roland Roberts,  PhD
6818 Madeline Court
Brooklyn,  NY 11220

-------- Original message --------
From: Daniel J Walsh <dwalsh(a)redhat.com&gt; 
Date: 05/28/2013  8:33 AM  (GMT-05:00) 
To: Roland Roberts <roland(a)astrofoto.org&gt; 
Cc: Dominick Grift <[e-mail]&gt;,selinux(a)lists.fedoraproject.org 
Subject: Re: SELinux, NIS, NFS, and /home, trouble with Fedora 18 converting
   user_home_dir_t to detault_t 
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/28/2013 08:03 AM, Roland Roberts wrote:
>  Yet normally /home is home_root_t. And in my case /data is a mount
> point
>  for other things; the actual disk is mounted at /data/home, so I thought I
>  was doing the equivalent of what the man page says.
>  
>  Roland -- Roland Roberts,  PhD 6818 Madeline Court Brooklyn,  NY 11220
>  
>  
>  
>  -------- Original message -------- From: Dominick Grift
>  <dominick.grift(a)gmail.com&gt; Date: 05/28/2013 4:13 AM (GMT-05:00) To: Roland
>  Roberts <roland(a)astrofoto.org&gt; Cc: selinux(a)lists.fedoraproject.org Subject:
>  Re: SELinux, NIS, NFS, and /home, trouble with Fedora 18 converting 
>  user_home_dir_t to detault_t
>  
>  
>  On Mon, 2013-05-27 at 19:01 -0400, Roland Roberts wrote:
>  
>  SELinux contexts for /home are treated a bit differently than other 
>  locations.
>  
>  Try instead: (from: man semanage):
>  
> > For home directories under top level directory, for example /disk6/home, 
> > execute the following commands. # semanage fcontext -a -t home_root_t
> > "/disk6" # semanage fcontext -a -e /home /disk6/home # restorecon -R -v
> > /disk6
>  
>  
> > I'm trying to clean up selinux contexts and having trouble. The system is
> > a new install of Fedora 18, but the home directories have been preserved
> > for a long time. Because the system runs boot on raid-1, it was installed
> > as Fedora 17 and then I used fedup to move to Fedora 18.
> > 
> > My home directories are automounted via NFS and an NIS map. I mount them 
> > on the clients with an explicit context:
> > 
> > 270 roland> ypcat auto.home 
> > -rw,soft,intr,tcp,context="system_u:object_r:user_home_t:s0" 
> > archos.rlent.pnet:/data/home/&
> > 
> > However, my troubles right now are confined to the server.
> > 
> > The real home directory is /data/home so /data/home/roland is mounted on 
> > /home/roland. All clients see the same mount point, even the server 
> > remounts this way.
> > 
> > Most of the selinux context information is wrong, probably because some 
> > of these files have been hanging around roughly since RedHat 3.0.3. Yes, 
> > really. Although the content has surely changed (e.g., .bashrc).
> > 
> > To get started, I've done this
> > 
> > semanage fcontext -a -t home_root_t /data/home semanage fcontext -a -t
> > user_home_dir_t '/data/home/(.*)' semanage fcontext -a -t lost_found_t
> > /data/home/lost+found restorecon -v -R /data/home
> > 
> > That gave the surprising result of doing absolutely nothing. So I 
> > brute-forced it and did
> > 
> > semanage fcontext -a -t home_root_t /data/home semanage fcontext -a -t
> > lost_found_t /data/home/lost+found for D in $LIST; do semanage fcontext
> > -a -t user_home_dir_t /data/home/$D; done restorecon -v -R /data/home
> > 
> > The above did not work for the lost+found directory. I haven't figured 
> > out why. I tried deleting all the contexts I had set and starting over 
> > and I tried setting the context just on lost+found repeatedly to no 
> > avail. lost+found remains default_t.
> > 
> > Next, I log in via ssh to my user account. Since I have X forwarding 
> > turned on, this results in an .Xauthority file being created. If I run 
> > (as root, from another window) restorecon, I get this
> > 
> > [root@archos ~]# cd /data/home/roland [root@archos roland]# restorecon -v
> > -R /data/home/roland restorecon reset /data/home/roland/.Xauthority
> > context 
> > unconfined_u:object_r:xauth_home_t:s0->unconfined_u:object_r:default_t:s0
> >
> >
> >  
So the file was created with the correct context, but it gets zapped
> > with restorecon. I can create a new file via touch and it gets
> created 
> > with the correct context
> > 
> > 268 roland> ls -Z foo -rw-rw-r--. roland roland
> > unconfined_u:object_r:user_home_t:s0 foo 269 roland> ls -Zad . 
> > drwxr-xr-x. roland roland system_u:object_r:user_home_dir_t:s0 .
> > 
> > But again, if I run restorecon, it gets converted to default_t.
> > 
> > I realize the whole NIS/NFS thing makes this problematic on the clients, 
> > but all of the above is on the server. I was hoping to get the file 
> > contexts fixed up, but even if I can get it to stop converting everything
> > back to default_t, I haven't got a clue about all the other contexts I
> > need to set (e.g., ssh_home_t for .ssh, but what else) and then I fear
> > they will just get reset, too.
> > 
> > So, what's going on here and how do I stop it? Then after that, how do I 
> > go about fixing all the default_t under my home directory to be what they
> > should be.
> > 
> > roland
> > 
>  
>  
>  
>  
>  -- selinux mailing list selinux(a)lists.fedoraproject.org 
>  https://admin.fedoraproject.org/mailman/listinfo/selinux
>   
In this case you want to label /data/home as equivalent to /home
and you probably want to label data with a label that most apps can read like
usr_t.


# semanage fcontext -a -t usr_t '/data(/.*)?'
# semanage fcontext -a -e /home /data/home



> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlGkpAIACgkQrlYvE4MpobMKdgCgyvOOSlMo+7wSO7qB52SMHFRT
> vUwAoIXc15OzcmadYZC+NANqMxKRSCve
> =EBci
> -----END PGP SIGNATURE-----