selinux: rhel5 x fedora 14

Stephen Smalley sds at tycho.nsa.gov
Thu Jan 13 13:26:01 UTC 2011


On Thu, 2011-01-13 at 08:02 -0200, Paulo Cavalcanti wrote:
> 
> 
> On Wed, Jan 12, 2011 at 7:07 PM, Daniel J Walsh <dwalsh at redhat.com>
> wrote:
>         -----BEGIN PGP SIGNED MESSAGE-----
>         Hash: SHA1
>         
>         
>         
>         On 01/12/2011 04:03 PM, Paul Howarth wrote:
>         > On Wed, 12 Jan 2011 13:02:21 -0500
>         > Daniel J Walsh <dwalsh at redhat.com> wrote:
>         >> On 01/12/2011 06:29 AM, Paulo Cavalcanti wrote:
>         >>> Hi,
>         >>>
>         >>> I have two HDs on my computer: one with rhel5 5.5 and the
>         other with
>         >>> fedora 14.
>         >>> Both systems share some directories located in a
>         common /home,
>         >>> mainly used by the httpd process.
>         >>>
>         >>> The problem is that selinux in fedora 14 uses
>         "unrestricted_u" by
>         >>> default for all users, which rel5 does not understand,
>         >>> and any file labeled that way is treated as "unlabeled_t"
>         in rhel5.
>         >>>
>         >>> I tried to relabel all files in Fedora 14 using "chcon -R
>         -u user_u
>         >>> -t user_home_t" , for instance,
>         >>> but every new file is still created as "unrestricted_u".
>         >>>
>         >>> I know very little about selinux, and I would like to know
>         how to
>         >>> force all files in F14 to be user_u,
>         >>> but keeping the user owning those files, unrestricted.
>         >>>
>         >>> Is that possible? Is there a better solution for not
>         having tons of
>         >>> denials in rhel5?
>         >>>
>         >>> Thanks.
>         >>>
>         >>> --
>         >>> Paulo Roma Cavalcanti
>         >>> LCG - UFRJ
>         >>>
>         >> One solution would be to mount with a context on one of the
>         platforms.
>         >>
>         >> On RHEL5 mount the users homedir with a context of nfs_t,
>         and set the
>         >> boolean to say allow nfs homedirs
>         >>
>         >>
>         >> mount -o
>         context="system_u:object_r:nfs_t:s0" /dev/ABC /home
>         >> setsebool -P use_nfs_home_dirs 1
>         >
>         > What happens with newly-created files whilst booted in
>         RHEL-5 in this
>         > case? What will Fedora 14 see them as?
>         >
>         > Paul.
>         
>         
>         nfs_t, i think so Stephens solution is probably better?  I
>         would hope in
>         stephens solution they would be labeled user_home_t.  But it
>         would
>         probably be smart to run restorecon -R -v ~/ When you login on
>         F14
>         -----BEGIN PGP SIGNATURE-----
>         Version: GnuPG v1.4.11 (GNU/Linux)
>         Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>         
>         
>         
> 
> I would like to thank you all for the suggestions.
> 
> In rhel5, I changed my fstab this way:
> 
> LABEL=/home             /home                   ext4
> defaults,context=user_u:object_r:user_home_t:s0        1 2 
> 
> 
> All the files labelled "unconfined_u:object_r:user_home_t:s0" in F14
> are seen
> as "user_u:object_r:user_home_t:s0" in rhel5, and my /var/log/mesages
> is not no longer
> full of denials. 
> 
> However, even allowing httpd to read user content on rhel5 (files
> labelled user_home_t, I guess),
> I still get some warnings from selinux troubleshooter. Does this flag
> really work on rhel5?

Can you show the actual messages from setroubleshoot or from the output
of /sbin/ausearch -m AVC -ts today -i?

> Does anyone think that using nfs_t (and setsebool -P use_nfs_home_dirs
> 1) would make any difference?
> Also, does anyone know whether rhel6 will be more "Fedora like", from
> an selinux point of view?

RHEL-6 includes a version of SELinux that is far more modern than
RHEL-5, naturally, and thus will look more like a modern Fedora (circa
Fedora 12/13, I think).  RHEL-5 was forked from Fedora 6 IIRC.

-- 
Stephen Smalley
National Security Agency



More information about the devel mailing list