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,
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
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 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
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@redhat.com mentioned.
Also, what about home directories?
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@redhat.com mentioned.
Also, what about home directories?
Sounds like a good idea. Could you submit a bugzilla. Thanks.
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@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
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)
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
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
selinux@lists.fedoraproject.org
-
Colin Walters -
Daniel J Walsh -
Ivan Gyurdiev -
Karsten Wade