On Tue, 2008-07-29 at 17:22 -0400, Mike Edenfield wrote: > Chris PeBenito wrote: > > > ifdef(`distro_redhat > > optional_policy(` > > tunable_policy(`samba_ > > oddjob_domtrans_ > > ') > > ') > > ',` > > tunable_policy(`samba_ > > unprivuser_create_ > > unprivuser_home_filetrans_ > > ') > > ') > > > > Hopefully my pseudopolicy makes sense. > > It does, but I wonder if it's making the policy more complex than it > needs. Right now, in the RedHat case, samba doesn't know nor care that > oddjob is being used to make home directories, since the PAM module runs > an external binary that transitions into its own domain, controlled by > the oddjob module. I'm not sure what actual policy rules could go into > the samba_oddjob case that would do anything useful, and I don't yet > have a RH or FC system up and running to test any changes on (thats in > the works, tho). > > IMHO I think the two best alternatives are: skip the distro-specific > rules and do the same thing in all cases I'd prefer this. > , or just do nothing at all in > the RedHat case. RedHat users really should never have to enable this > option anyway, but if they do I don't think it opens any major new > security risks: samba already needs to have full read/write permission > to home directory *content* (based on the existing enable_home_dirs > tunable) for this to make any sense, and I think I've fixed the policy > so it can only create new home directories, not delete or rename them. > > Would it be sufficient warning to add this to the .te file so it shows > up in the booleans.conf file as such: > > ## <desc> > ## <p> > ## Allow samba to create new home directories. (Not recommended > ## for RedHat-based systems where oddjob is available.) > ## </p> > ## </desc> > gen_tunable(samba_create_home_dirs, false) I don't think its necessary. Mentioning oddjob doesn't do anything since if they enable oddjob in samba, with the current policy, it will fail, regardless if this tunable is on or off. > >>>> +interface(`unprivuser_create_home_dirs',` > >>>> + unprivuser_home_filetrans_home_dir($1) > >>>> + unprivuser_manage_home_dirs($1) > >>>> +') > >>> "Create" just means directory create, but you have the full manage > >>> permission set, in addition to a filetrans. > >> I think I did go a bit overboard with the manage permissions. I'd > >> copied these from the oddjob's policy, but I notice that oddjobs also > >> permits deleting home directories, which probably isn't needed here. > >> > >> The filetrans is needed, though, because without it, the created home > >> directories were getting labeled home_root_t instead of user_home_dir_t. > >> It also needs to copy the template files in and label them correctly, > >> like the user_home_ssh_t on .ssh, etc. I'll narrow this down. > > > > Thats fine, but the filetrans shouldn't be included in the create > > interface itself. > > Ok, but I'm a little confused then... if I move the filetrans call out > of the interface, then it becomes just a call into an existing > interface. Am I misunderstanding something? I think I'm having trouble > determining how granular I should make interfaces like this. Interfaces should not have side effects. If you have a create interface and it does something else like filetrans, filetrans is a side effect. The tunable should be: tunable_policy( unprivuser_create_home_dirs() unprivuser_home_filetrans_home_dir() ) > After your previous response, I updated the interface to use more > specific rules, but it still does the same basic stuff. For this, I'm > using "create" not in the low-level "make directory entry in /home" > sense, but in the higher level "do what needs to be done to end up with > a fully functional home directory" sense. Is that where I'm getting > confused? Would it help to name the interface something different, like: > > interface(`unprivuser_generate_full_home_dir',` > gen_require(` > type user_home_t, user_home_dir_t; > ') > > # Create home directory itself, label as user_home_dir_t > files_search_home($1) > files_home_filetrans($1, user_home_dir_t, dir) > > # Copy /etc/skel tree into new home directory, label as > # user_home_t > filetrans_pattern($1, user_home_dir_t, user_home_t, > notdevfile_class_set) > rw_files_pattern($1, user_home_t, user_home_t) > add_entry_dirs_pattern($1, user_home_t, user_home_t) > ') Perhaps. But I think the name needs work. You'd also want to provide rules for reading /etc/skel too. -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
