Bug 672106

I forgot to mention that you also have to set

<mkmountpoint enable="1" remove="true" />

in your /etc/security/pam_mount.conf.xml file to get it to attempt to auto create a home directory for mounting on.

Could we do something with pam_oddjob_mkhomedir?  pam_mount is not something we really want to support with SELinux, since mounting is a very powerful tool and basically makes confinement of these login programs useless.

Thanks for mentioning oddjobs.  I hadn't realized there was such a service.

I am wondering if you could be more specific with regard to my suggestion and mounting making confinement of these login programs useless.  Specifically, what exactly does this this open up that wasn't already open before.

My understanding of the above lines is that it

 - causes directories created under directories of the home_root_t type (i.e., /home) by the sshd_t domain (i.e., sshd) to be of the fuse_tmp_t type and
 - gives the sshd_t domain (i.e., sshd) permission to manage fuse_tmp_t directories (e.g., to change their ownerships to the appropriate user).

If you manage to compromise sshd, the most I can see this allowing you to do is possibly sort of denial of service attack through mucking with their home directory mount point.  Considering that a compromised sshd will allow you to directly transition to them though, I don't really see this as a gain.

Is there something additional I'm not understanding here?

Thanks!  -Tyson

I am worried about a limited compromised sshd not a fully compromised one.  A fully compromised one can take over the entire machine.

For example getting sshd to read a file and send it back to the client.  

What were your original avc's when you tried to setup pam_mount to create a direcory under /home?

I would prefer you to do something like

create the directory as user_home_dir_t, which you can do now by turning on the 
 allow_polyinstantiation boolean.

Then I guess you would need to allow the login apps to mound fusefs on top of this directory.

Hi Daniel,

What are you meaning by my original avc's?  The only changes I've made to my selinux setup to enable this is to

1 - set the use_fusefs_home_dirs boolean,

2 - add the custom module given above, and

3 - also add the fs_search_fusefs(sshd_t) as per bug 672104.

This third item is only so sshd can cd into your directory as a final step.  Without it, everything still work fine, you just windup being dumped out in the root directory and then have to manual switch to your directory.

I'm guessing the answer to your question then must be whatever the defaults are.

If you are asking how things work with the default setup, the default selinux setup lets everything work after setting use_fusefs_home_dirs except

1 - the creation of mount points under home and

2 - dumping you out in / instead of your directory.

That is, if you manually create the mount points and don't mind having to cd into your directory after login, it works out of the box.

Cheers!  -Tyson

I am talking about

policy_module(custom, 1.0)

type fuse_tmp_t;
files_tmp_file(fuse_tmp_t)
files_mountpoint(fuse_tmp_t)

gen_require(`
        type xdm_t;
        type sshd_t;
')

tunable_policy(`use_fusefs_home_dirs',`
       allow xdm_t fuse_tmp_t:dir manage_dir_perms;
       files_home_filetrans(xdm_t, fuse_tmp_t, dir)

       allow sshd_t fuse_tmp_t:dir manage_dir_perms;
       files_home_filetrans(sshd_t, fuse_tmp_t, dir)
')

Why create a fuse_tmp_t?  Why not use the standard label for home dirs user_home_dir_t, which these domains can currently create, when a boolean is turned on.  In this case don't you mount the fusefs on top of this directory?

I was really just followed the automount example (which uses creates a similar type automount_tmp_t).  I figured this was worthwhile as otherwise I would have had give the ssh_t domain extra control over local accounts (user_home_dir_t).

It does seem that setting allow_polyinstantiation allows the sshd_t domain to create directories of type user_home_dir_t.  Combined with

gen_require(`
        type xdm_t;
        type sshd_t;
        type user_home_dir_t;
')

tunable_policy(`use_fusefs_home_dirs',`
        files_home_filetrans(xdm_t, user_home_dir_t, dir)
        files_home_filetrans(sshd_t, user_home_dir_t, dir)
')

it works.  If I don't include the files_home_filetrans commands I get

type=AVC msg=audit(1295966006.239:59374): avc:  denied  { create } for  pid=16579 comm="sshd" name="tyson" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:home_root_t:s0 tclass=dir
type=AVC msg=audit(1295966006.240:59375): avc:  denied  { setattr } for  pid=16579 comm="sshd" name="tyson" dev=dm-1 ino=3145764 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:home_root_t:s0 tclass=dir

I really can't find where in the policy files the sshd_t domain is getting the extra { create, setattr } permissions via the allow_polyinstantiation boolean though, so I don't know what else setting this opens up.

Cheers!  -Tyson

Ah.  I found it.  It looks like it gains the permissions through

ssh_server_template -> auth_login_pgm_domain -> attribute polydomain -> userdom_manage_user_home_contents{dirs,files}

Unless I'm mistaken, this means that setting allow_polyinstantiation gives the sshd_t domain pretty much full reign in the home directory of all local users (i.e., ones not mounted).  I believe my earlier proposal avoids this.

Cheers!  -Tyson

Tyson, I agree allowing it to just manage user_home_dir_t would be better then setting the boolean or just allow it,

tunable_policy(`use_fusefs_home_dirs',`
          allow xdm_t home_root_t:dir manage_dir_perms;
')

Might be the simplest solution.  

Is this a standard use of pam_mount?

The thing we like about use sshfs with pam_mount is it is a much simpler alternative to setting up a Kerberos infrastructure for securely exporting home directories to workstations in insecure environments.  I presume other people must be using it for this as well, as googling turns up a couple of tutorials.

I guess it's a question of whether creating a new type is worth not having to allow sshd_t domain to also be able to create and change the attributes on home_dir_t directories (actually, manage_dir_perms gives more than this, but I believe we could go with just adding setattr_dir_perms and create_dir_perms).

For reference, I believe the sshd_t domain currently has {list,rw}_dir_perms for the home_dir_t (userdom_user_home_dir_filetrans -> filetrans_pattern and file_search_home).  Strictly I suspect this is already an overkill.  From the documentation, the user_dome_user_home_dir_filetrans macro is suppose to just allow objects that transition to the given type to be created (as apposed to full rw access).  Likely it should really have expanded to filetrans_add_pattern, which would have given just {list,add_entry}_dir_perms.

Anyway, just my observations.  Whatever you guys figure is best.

Cheers!  -Tyson

This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping