Bug 144516

Summary: RFE: Boolean: smbd_enable_homedirs
Product: [Fedora] Fedora Reporter: Ivan Gyurdiev <ivg231>
Component: selinux-policy-targetedAssignee: Daniel Walsh <dwalsh>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-01-13 00:27:21 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Replace unconfined.te with this none

Description Ivan Gyurdiev 2005-01-07 21:28:27 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041228 Firefox/1.0 Fedora/1.0-8

Description of problem:
Please add this, so that smbd can export homedirs properly.
It does this by default with the current samba config, I think.

[homes]
        comment = Home Directories
        browseable = no
        writeable = yes


audit(1105133058.295:0): avc:  denied  { search } for  pid=17652
exe=/usr/sbin/smbd name=/ dev=dm-2 ino=2
scontext=user_u:system_r:smbd_t tcontext=system_u:object_r:home_root_t
tclass=dir


Version-Release number of selected component (if applicable):
selinux-policy-targeted-1.19.17-3

How reproducible:
Always

Steps to Reproduce:
1. See summary
    

Additional info:

Comment 1 Daniel Walsh 2005-01-07 21:51:05 UTC
Seems we need a boolean for both sides.  IE you have a home directory
on a samba server and you want the samba server to share it out to
your network.  Second you have your actual home directories on a samba
server.  (Like NFS homedir).

bool smbd_enable_homedirs false;
bool use_smbd_home_dirs false;

Comment 2 Ivan Gyurdiev 2005-01-10 18:26:08 UTC
So... I also need samba users to be able
to put stuff in ~/webserver which is labeled httpd_sys_content_t
(it's a symlink to /var/www/html.username which is their virtual
server).

What to do about that? New type somewhere (smbd_httpd_content_t)?

Comment 3 Daniel Walsh 2005-01-10 18:32:16 UTC
I would do custom policy

r_dir_file(smbd_t, httpd_content_t)

Or something like that.



Comment 4 Ivan Gyurdiev 2005-01-10 19:14:04 UTC
What happened to the deprecation of the shell for GUI tools.
Seems to me it won't happen anytime soon if users have
to edit M4 macro policies by hand to accomplish a simple 
security task.   

Where's the nautilus integration with ACLs? SELinux? Samba?






Comment 5 Daniel Walsh 2005-01-10 19:20:28 UTC
I don't know I am the SELinux guy.  :^).  Actually we are adding the
ability to view security contexts from nautilus.  Problem is how do
you allow them to set it.  

I don't know about ACL's.

Samba we are just beginning to work on.  

I would also argue that you are trying to do a "simple security task"
of sharing files via samba and html while running selinux.  This is
not exactly the norm.

Of course this is open source so if we could get some students from a
fine Ivy league institution to do some of it ...  :^)


Comment 6 Ivan Gyurdiev 2005-01-10 19:47:36 UTC
Why can't there be more than one security context per file?
Is this technically not feasable? That seems to be at the root of the
problem? My data isn't a samba share only, or http content only.
It's both, at the same time. If the files could be labeled as such, 
the type checker could permit the operation if any matching context
permits it. Or, if that's not possible, couldn't the procedure of
creating a type inheriting the exact properties of several other types
be automated somehow. 

It's good to know that nautilus will be integrated with some of those
things.

"I would also argue that you are trying to do a "simple security task"
of sharing files via samba and html while running selinux.  This is
not exactly the norm."

It is a simple task. I've seen this used in practice (even though it's
an awful idea, I'm just doing this for fun). Something more common I
suppose would be ftp + http. The task only looks complicated because
SElinux makes it so.


Comment 7 Daniel Walsh 2005-01-10 20:04:02 UTC
Your first question should be brought up for discussion on the selinux
list.  We are working on a concept of configurable contexts.  IE
contexts that a user is likely to modify.  samba_share_t, ftp_anon_t,
httpd_sys_content_t ...  We are looking to extracting this contexts
out of policy.conf in order that we can give a list to users with
suggestions on which configurable context they would want to use.  I
am working, now to stop restorecon/setfiles from overwriting these
contexts.  So now in policy we have added a configurable attribute to
these contexts and you could create a boolean to allow "sharing" tools
to share "configurable" data types.


Currently rsync and ftp share ftp_anon_t for their data.


Comment 8 Ivan Gyurdiev 2005-01-11 18:20:07 UTC
Okay, back to the subject of this bug. 
Testing homedirs...

First, it doesn't work at all unless I have this:

--- samba.te.old        2005-01-11 10:48:30.081145001 -0700
+++ samba.te    2005-01-11 11:05:15.669063244 -0700
@@ -122,6 +122,7 @@
 bool samba_enable_home_dirs false;

 if ( samba_enable_home_dirs ) {
+allow smbd_t home_root_t:dir { getattr search };
 allow smbd_t user_home_dir_t:dir create_dir_perms;
 create_dir_file(smbd_t, user_home_t)
 }

Second, I get denails on sockets:

audit(1105466922.985:0): avc:  denied  { getattr } for  pid=19412
exe=/usr/sbin/smbd path=/home/phantom/.Devhelp.phantom dev=dm-2
ino=327432 scontext=root:system_r:smbd_t
tcontext=system_u:object_r:user_home_t tclass=sock_file
audit(1105466922.986:0): avc:  denied  { getattr } for  pid=19412
exe=/usr/sbin/smbd path=/home/phantom/.marlin.phantom dev=dm-2
ino=326490 scontext=root:system_r:smbd_t
tcontext=user_u:object_r:user_home_t tclass=sock_file

Third, anything created in the mounted share is
labeled user_home_dir_t. I don't know what the difference
is with user_home_t, but there is something fishy about all
this and it's not working as it should. 

restorecon says user_home_dir_t is wrong.
The current samba policy allows creation of directories
as user_home_dir_t, but not files. This is the result:

(/home/phantom is mounted on /root/tmp via samba)

[root@cobra tmp]# touch flp
touch: cannot touch `flp': No such file or directory
[root@cobra tmp]# mkdir flp
[root@cobra tmp]# cd ..
[root@cobra ~]# umount ./tmp
[root@cobra ~]# restorecon /home/phantom/flp
restorecon reset context
/home/phantom/flp:root:object_r:user_home_dir_t->system_u:object_r:user_home_t
[root@cobra ~]#



Comment 9 Daniel Walsh 2005-01-11 19:18:37 UTC
Created attachment 109632 [details]
Replace unconfined.te with this

Comment 10 Daniel Walsh 2005-01-11 19:19:45 UTC
if ( samba_enable_home_dirs ) {
allow smbd_t home_root_t:dir { getattr search };
allow smbd_t home_dir_type:dir { getattr search };
allow smbd_t home_type:dir create_dir_perms;
file_type_auto_trans(smbd_t, user_home_dir_t, user_home_t)
dontaudit smbd_t home_type:{ sock_file fifo_file chr_file blk_file }
r_file_perms;
}
And try this?

Comment 11 Ivan Gyurdiev 2005-01-11 20:00:09 UTC
Okay, everything seems to work now (with the exception of 
~/webserver, which I'll have to take care of somehow)

Do you know why this happens though?

coreutils problem with smbfs, or is it supposed to do that?

[root@cobra tmp]# mkdir d
[root@cobra tmp]# touch d/a
[root@cobra tmp]# rmdir d
rmdir: `d': Permission denied
[root@cobra tmp]# cd ..
[root@cobra ~]# umount ./tmp
[root@cobra ~]# rmdir /home/phantom/d
rmdir: `/home/phantom/d': Directory not empty
[root@cobra ~]# rm -Rf /home/phantom/d
[root@cobra ~]#


Comment 12 Daniel Walsh 2005-01-11 20:33:34 UTC
Ok I will update policy to match what I gave you.  I would submit you
other questioin as a separate bug on samba.  
I have no idea.

Dan