samba policy updates

services/samba.te line 396

Quoted 8 lines · Mike Edenfield

services/samba.te +8 -0

+tunable_policy(`samba_create_home_dirs',`
+	ifdef(`distro_redhat', `
+		refpolicywarn(`Use of samba_create_home_dirs is discouraged.  Please use pam_oddjob_mkhomedir instead.')
+	', `
+		unprivuser_create_home_dirs(smbd_t)
+		allow smbd_t self:capability chown;
+	')
+')

I don't think this has the effect that you're trying to get. The ifdef is resolved during build time, and the tunable is resolved at runtime. So the warning message won't do any good for most redhat users (and it leaves them with a noop samba_create_home_dirs tunable).

roles/unprivuser.if line 161

Quoted 4 lines

roles/unprivuser.if +4 -0

+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.

Quoted 14 lines · Chris PeBenito

services/samba.te line 396

Quoted 8 lines · Mike Edenfield

services/samba.te +8 -0

+tunable_policy(`samba_create_home_dirs',`
+	ifdef(`distro_redhat', `
+		refpolicywarn(`Use of samba_create_home_dirs is discouraged.  Please use pam_oddjob_mkhomedir instead.')
+	', `
+		unprivuser_create_home_dirs(smbd_t)
+		allow smbd_t self:capability chown;
+	')
+')

I don't think this has the effect that you're trying to get. The ifdef is resolved during build time, and the tunable is resolved at runtime. So the warning message won't do any good for most redhat users (and it leaves them with a noop samba_create_home_dirs tunable).

I wasn't sure if that would work; I know Dan has expressed a preference for RH users to use oddjob for this, but I didn't know if there was any way to enforce that. I certainly didn't want it to silently do nothing.
Is there a correct place to document this preference?

Quoted 7 lines

roles/unprivuser.if line 161

Quoted 4 lines

roles/unprivuser.if +4 -0

+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.

ifdef(`distro_redhat
optional_policy(`

    tunable_policy(`samba_
      oddjob_domtrans_
    ')

')
',`
tunable_policy(`samba_
unprivuser_create_
unprivuser_home_filetrans_
')
')

Hopefully my pseudopolicy makes sense.

Quoted 6 lines

Quoted 6 lines

roles/unprivuser.if line 161

Quoted 4 lines

roles/unprivuser.if +4 -0

+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.

Quoted 5 lines

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.

Quoted 13 lines · Chris PeBenito

ifdef(`distro_redhat
optional_policy(`

    tunable_policy(`samba_
      oddjob_domtrans_
    ')

')
',`
tunable_policy(`samba_
unprivuser_create_
unprivuser_home_filetrans_
')
')

Quoted 1 line

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

, 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)

Quoted 15 lines

Quoted 14 lines

Quoted 6 lines

roles/unprivuser.if line 161

Quoted 4 lines

roles/unprivuser.if +4 -0

+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.

Quoted 2 lines

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.

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)
')

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()
)

Quoted 8 lines · Christopher J. PeBenito

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()
)

Ok, I think I get it now. Sorry for being kinda dense :)

So, what I should have dome is something like this:

tunable_policy (
unprivuser_home_filetrans_home_dir()
unprivuser_create_home_dir()
unprivuser_add_entry_home_dir()
)

with two new interfaces:

unprivuser_create_home_dir (
allow user_home_dir_t:dir create_dir_perms
)

unprivuser_add_entry_home_dir (
allow user_home_dir_t:dir add_entry_dir_perms
)

Quoted 27 lines · Mike Edenfield

Quoted 8 lines · Christopher J. PeBenito

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()
)

Ok, I think I get it now. Sorry for being kinda dense :)

So, what I should have dome is something like this:

tunable_policy (
unprivuser_home_filetrans_home_dir()
unprivuser_create_home_dir()
unprivuser_add_entry_home_dir()
)

with two new interfaces:

unprivuser_create_home_dir (
allow user_home_dir_t:dir create_dir_perms
)

Quoted 3 lines

unprivuser_add_entry_home_dir (
allow user_home_dir_t:dir add_entry_dir_perms
)

Why do you need the add_entry? You just want to create the /home/foouser directory right? Add_entry is for when you want to create an object in that type of directory.