Samba file server

[Ivan Gyurdiev]

Hi,

I have a fairly trivial setup ( I think ) that I'd like to get working
under SElinux. 

I have a bunch of data on /data, which is its own LVM logical volume.
I have symlinks to the parts of the data in /data/smb that I'd like to
export via smb. 

My server also exports user home directories and all printers.

The problem is: 
	Stuff on /data is labeled: system_u:object_r:default_t 
	Stuff on /home is labeled: system_u:object_r:user_home_dir_t
		under system_u:object_r:home_root_t 

I get:

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

audit(1105107520.694:0): avc:  denied  { search } for  pid=32629
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

- How can I address this situation?
- What if I wanted to share /data over httpd as well?

Thanks for any help,

-- 
Ivan Gyurdiev <ivg2(a)cornell.edu&gt;
Cornell University

[Karsten Wade]

	On Fri, 2005-01-07 at 08:09 -0700, Ivan Gyurdiev wrote:
>  Hi,
>  
>  I have a fairly trivial setup ( I think ) that I'd like to get working
>  under SElinux. 
>  
>  I have a bunch of data on /data, which is its own LVM logical volume.
>  I have symlinks to the parts of the data in /data/smb that I'd like to
>  export via smb. 
>  
>  My server also exports user home directories and all printers.
>  
>  The problem is: 
>  	Stuff on /data is labeled: system_u:object_r:default_t 
>  	Stuff on /home is labeled: system_u:object_r:user_home_dir_t
>  		under system_u:object_r:home_root_t 
>  
>  I get:
>  
>  audit(1105106751.784:0): avc:  denied  { search } for  pid=32352
>  exe=/usr/sbin/smbd name=/ dev=dm-1 ino=2 scontext=user_u:system_r:smbd_t
>  tcontext=system_u:object_r:default_t tclass=dir
>  
>  audit(1105107520.694:0): avc:  denied  { search } for  pid=32629
>  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 
You have /root on this share?  Interesting.  I'm not sure you can do
what I describe below in /root.

>  - How can I address this situation? 
Try relabeling the portions of /data that you want to have
user_home_dir_t and user_home_t:

chcon -t user_home_dir_t /data/smb
cd /data/smb
chcon -R -r user_home_t ./*

>  - What if I wanted to share /data over httpd as well? 
Off the top of my head, I don't think you can both share /data over
httpd and have it be normal user home directory data.  The types are
distinctly separate.  The normal procedure is to have an e.g.
public_html/ folder, which would have a different type.

There is a Boolean value for httpd that will allow httpd to access user
directories, for the purpose of serving content that is labeled
appropriately.  You can set this using system-config-securitylevel,
SELinux tab > Modify SELinux Policy  > Allow HTTPD to read home
directories.  You then need to relabel the content you want served:

chcon -t httpd_sys_content_t /path/to/public_html/

The folder gains the new type, and all children created inside of that
gain the type.

This guide has more information on customizing Apache and SELinux:

http://fedora.redhat.com/docs/selinux-apache-fc3/sn-user-homedir.html
-- 
Karsten Wade, RHCE, Sr. Tech Writer
a lemon is just a melon in disguise
http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115  5F1B D992 0E06 AD0E 0C41

[Ivan Gyurdiev]

>  You have /root on this share?  Interesting.  I'm not sure you can
> do
>  what I describe below in /root. 
No I don't. That's what the avc output says. I have no idea why it says
that - I guess it prints the path relative to the volume mount point, 
not to the global /.
>  
>  Try relabeling the portions of /data that you want to have
>  user_home_dir_t and user_home_t:
>  
>  chcon -t user_home_dir_t /data/smb
>  cd /data/smb
>  chcon -R -r user_home_t ./* 
That sounds like a hack. This isn't a home directory so why
should I label it as such. It's a bunch of common files.
In addition to that I want home directories under /home.
Since smbd currently fails to read even those, how would labeling
/data user_home_t help?

=============

Part of the problem in my mind is that I do not know what
the SElinux types are, which ones I need to do what I want,
and how to add new ones to perform this simple task. 

Consider traditional UNIX permissions. There's a straightforward
procedure for doing what I want. I create a group called data.
I put whoever I want in it (user1, user2, user3, httpd..). Then 
I chgrp /data with that. Nice and simple. I forget what smbd does - I
think it checks to see if the UNIX user that you're logged in with
has access to that folder.

What's the SElinux equivalent? 

-- 
Ivan Gyurdiev <ivg2(a)cornell.edu&gt;
Cornell University

[Daniel J Walsh]

Ivan Gyurdiev wrote:

> >You have /root on this share?  Interesting.  I'm not sure you
> can do
> >what I describe below in /root.
> >    
> >
>
> No I don't. That's what the avc output says. I have no idea why it says
> that - I guess it prints the path relative to the volume mount point, 
> not to the global /.
>   
>
> >Try relabeling the portions of /data that you want to have
> >user_home_dir_t and user_home_t:
> >
> >chcon -t user_home_dir_t /data/smb
> >cd /data/smb
> >chcon -R -r user_home_t ./*
> >    
> >
>
> That sounds like a hack. This isn't a home directory so why
> should I label it as such. It's a bunch of common files.
> In addition to that I want home directories under /home.
> Since smbd currently fails to read even those, how would labeling
> /data user_home_t help?
>
> =============
>
> Part of the problem in my mind is that I do not know what
> the SElinux types are, which ones I need to do what I want,
> and how to add new ones to perform this simple task. 
>
> Consider traditional UNIX permissions. There's a straightforward
> procedure for doing what I want. I create a group called data.
> I put whoever I want in it (user1, user2, user3, httpd..). Then 
> I chgrp /data with that. Nice and simple. I forget what smbd does - I
> think it checks to see if the UNIX user that you're logged in with
> has access to that folder.
>
> What's the SElinux equivalent? 
>
>   
>  
I think you want to label them samba_share_t.

chcon -R -t samba_share_t  /data

[Ivan Gyurdiev]

>  I think you want to label them samba_share_t.
>  
>  chcon -R -t samba_share_t  /data 
Excellent. Where can I find such information in the future?
There must be a better way of communicating to the user what 
the needed contexts are instead of looking at the policy
(which is in binary form on my machine).
How about integrating some sort of check in 
system-config-samba that asks if it should
relabel those shares for you when you add them?

Or some sort of document (for Samba) like the one for HTTP that 
kwade(a)redhat.com mentioned.

Also, what about home directories?

-- 
Ivan Gyurdiev <ivg2(a)cornell.edu&gt;
Cornell University

[Daniel J Walsh]

Ivan Gyurdiev wrote:

> >I think you want to label them samba_share_t.
> >
> >chcon -R -t samba_share_t  /data
> >    
> >
>
> Excellent. Where can I find such information in the future?
> There must be a better way of communicating to the user what 
> the needed contexts are instead of looking at the policy
> (which is in binary form on my machine).
> How about integrating some sort of check in 
> system-config-samba that asks if it should
> relabel those shares for you when you add them?
>
> Or some sort of document (for Samba) like the one for HTTP that 
> kwade(a)redhat.com mentioned.
>
> Also, what about home directories?
>
>   
>  
Sounds like a good idea.  Could you submit a bugzilla.  Thanks.

[Karsten Wade]

On Fri, 2005-01-07 at 13:57 -0700, Ivan Gyurdiev wrote:

>  Or some sort of document (for Samba) like the one for HTTP that 
>  kwade(a)redhat.com mentioned. 
The Fedora docs project needs writers to tackle tutorials like what you
describe.  If you or anyone you know is interested, send them over to
http://fedora.redhat.com/projects/docs/.

- Karsten
-- 
Karsten Wade, RHCE, Sr. Tech Writer
a lemon is just a melon in disguise
http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115  5F1B D992 0E06 AD0E 0C41

[Colin Walters]

On Fri, 2005-01-07 at 13:29 -0700, Ivan Gyurdiev wrote:

>  That sounds like a hack. This isn't a home directory so why
>  should I label it as such. It's a bunch of common files. 
Well, that's currently the type we use for data that users can modify.
It may be a bit weird given the name, but if from a security perspective
the files elsewhere are equivalent to the user's $HOME, then giving them
the same label makes sense.

>  Part of the problem in my mind is that I do not know what
>  the SElinux types are, which ones I need to do what I want,
>  and how to add new ones to perform this simple task.  
Right; this is something that should definitely be documented somewhere.
Both the purpose of existing types, as well as how to add new ones for
specific purposes.

>  Consider traditional UNIX permissions. There's a straightforward
>  procedure for doing what I want. I create a group called data.
>  I put whoever I want in it (user1, user2, user3, httpd..). Then 
>  I chgrp /data with that. Nice and simple.  
Offtopic, but: you really want to use ACLs instead of groups; much
simpler then mucking about with groups.

>  I forget what smbd does - I
>  think it checks to see if the UNIX user that you're logged in with
>  has access to that folder. 
It uses setfsuid, IIRC.

>  What's the SElinux equivalent?  
You create a new type:

type foodata_t, file_type, sysadmfile;

Then grant permissions from other domains to it:

r_dir_file(user1_t, foodata_t)
create_dir_file(user2_t, foodata_t)
create_dir_file(samba_t, foodata_t)

[Karsten Wade]

On Fri, 2005-01-07 at 15:52 -0500, Colin Walters wrote:
>  On Fri, 2005-01-07 at 13:29 -0700, Ivan Gyurdiev wrote:
>  
>  > That sounds like a hack. This isn't a home directory so why
>  > should I label it as such. It's a bunch of common files.
>  
>  Well, that's currently the type we use for data that users can modify.
>  It may be a bit weird given the name, but if from a security perspective
>  the files elsewhere are equivalent to the user's $HOME, then giving them
>  the same label makes sense. 
Heh, I knew I had the right answer but I wasn't sure why it was the
only right answer. :) (me refers to grogginess mentioned earlier)

>  > Part of the problem in my mind is that I do not know what
>  > the SElinux types are, which ones I need to do what I want,
>  > and how to add new ones to perform this simple task. 
>  
>  Right; this is something that should definitely be documented somewhere.
>  Both the purpose of existing types, as well as how to add new ones for
>  specific purposes. 
Documenting all the types sounds like a monumental task.  It is also
pretty dry reading (and writing).  I could go on and on here, but IMHO
this is not a manual documentation task.  Similar is the idea of having
a tutorial for every domain.  Already that is an unwieldy idea for the
targeted policy, and I *shudder* just thinking about it for the strict
policy.

Which brings us to a procedural and programmatic solution, the kind I
much prefer.  I'd like to hear developer ideas on this.

Also, it would be nice to integrate this with the online documentation,
meaning manual and info pages.  Perhaps the pages could have an include
that pulls a list of appropriate types from the policy.  For example,
the man page for sshd(8) would pull a formatted list of types (and tips)
from /etc/selinux/policyname/docs/sshd.doc.  The file sshd.doc is
generated in the policy build (and supplied in binary policy and can be
build from policy source), combining sshd.tips with an extraction of the
types from the current policy.  Similarly, sys.doc could be generated to
give a view into all _sys_ types, sysadmr.doc could list all the things
the sysadm_r role can do, and so forth.

Essentially, all this stuff is there to find in the policy and using
analysis tools such as apol.  Be nice to make it easier for our friends
the sysadmins than to make them into policy analysts. :)

- Karsten
-- 
Karsten Wade, RHCE, Sr. Tech Writer
a lemon is just a melon in disguise
http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115  5F1B D992 0E06 AD0E 0C41

[Karsten Wade]

On Fri, 2005-01-07 at 13:29 -0700, Ivan Gyurdiev wrote:
>  > You have /root on this share?  Interesting.  I'm not sure
> you can do
>  > what I describe below in /root.
>  
>  No I don't. That's what the avc output says. I have no idea why it says
>  that - I guess it prints the path relative to the volume mount point, 
>  not to the global /. 
Right, it does.  I was blurry eyed this morning. :) I thought I
understood what was happening to you.  Are you running the strict or
rawhide policy?  Samba wasn't covered in the targeted policy for FC3,
so /usr/sbin/smbd wouldn't have the type smb_t under that policy

>  > Try relabeling the portions of /data that you want to have
>  > user_home_dir_t and user_home_t:
>  > 
>  > chcon -t user_home_dir_t /data/smb
>  > cd /data/smb
>  > chcon -R -r user_home_t ./*
>  
>  That sounds like a hack. This isn't a home directory so why
>  should I label it as such. It's a bunch of common files.
>  In addition to that I want home directories under /home.
>  Since smbd currently fails to read even those, how would labeling
>  /data user_home_t help? 
Sorry, I misread your intent, I thought your task was mounting home
directories.

I don't have a modern strict or rawhide targeted policy installed
anywhere right now and I would need that to analyze what the policy is
regulating against what you are trying to do.

>  Part of the problem in my mind is that I do not know what
>  the SElinux types are, which ones I need to do what I want,
>  and how to add new ones to perform this simple task.  
In the targeted policy, you won't have to worry about that.  Choosing to
run the strict or rawhide policy puts you in an area that is more
complex.  If you accept that complexity, you accept that you are going
to need to customize policy or file bugs/feature requests (as Dan Walsh
requested.)  The documentation is catching up with the code.  Slowly. :/

- Karsten
-- 
Karsten Wade, RHCE, Sr. Tech Writer
a lemon is just a melon in disguise
http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115  5F1B D992 0E06 AD0E 0C41