I think one thing that would help would be making the sets of example httpd module configurations self-documentating w.r.t. SELinux for some of the modules.
So for instance, how do I get Subversion/mod_dav_svn working with an SELinux-enabled httpd? Can we make it such that an SVN repos is as easy to set up as:
# cd /src/svn # svnadmin create mystuff # vi /etc/httpd/conf.d/subversion.conf - uncomment the defaults?
even with SELinux enabled? The commented default in subversion.conf here could be:
<Location /repos> DAV svn SVNParentPath /srv/svn </Location>
A more generic example would be if we provide a /srv/www directory or something to which the httpd domain is allowed read+write access by default; somewhere to put the PHP webapps.
Does this make sense?
joe
On Tue, 2004-11-16 at 13:21 +0000, Joe Orton wrote:
I think one thing that would help would be making the sets of example httpd module configurations self-documentating w.r.t. SELinux for some of the modules.
It would be nice to go through more possible configurations and try them; so far we've only done a few.
So for instance, how do I get Subversion/mod_dav_svn working with an SELinux-enabled httpd? Can we make it such that an SVN repos is as easy to set up as:
# cd /src/svn # svnadmin create mystuff # vi /etc/httpd/conf.d/subversion.conf
- uncomment the defaults?
Well, given that the path /src/ doesn't exist by default right now, we can't ensure it's labeled correctly out of the box. Maybe we could have default configuration use /var/www/.
A more generic example would be if we provide a /srv/www directory or something to which the httpd domain is allowed read+write access by default; somewhere to put the PHP webapps.
/srv/www should probably be just be labeled the same as /var/www by default. Since the default label is httpd_sys_content_t, which in the default boolean set httpd_t is allowed to write to, PHP apps storing e.g. a SQLite database there should work.
On Tue, Nov 16, 2004 at 01:56:56PM -0500, Colin Walters wrote:
On Tue, 2004-11-16 at 13:21 +0000, Joe Orton wrote:
I think one thing that would help would be making the sets of example httpd module configurations self-documentating w.r.t. SELinux for some of the modules.
It would be nice to go through more possible configurations and try them; so far we've only done a few.
I'll try to go through more of the modules in /etc/httpd/conf.d/*.conf.
So for instance, how do I get Subversion/mod_dav_svn working with an SELinux-enabled httpd? Can we make it such that an SVN repos is as easy to set up as:
# cd /src/svn # svnadmin create mystuff # vi /etc/httpd/conf.d/subversion.conf
- uncomment the defaults?
Well, given that the path /src/ doesn't exist by default right now, we can't ensure it's labeled correctly out of the box. Maybe we could have default configuration use /var/www/.
That would work too.
A more generic example would be if we provide a /srv/www directory or something to which the httpd domain is allowed read+write access by default; somewhere to put the PHP webapps.
/srv/www should probably be just be labeled the same as /var/www by default. Since the default label is httpd_sys_content_t, which in the default boolean set httpd_t is allowed to write to, PHP apps storing e.g. a SQLite database there should work.
httpd_t *cannot* write to anything labelled with httpd_sys_content_t by default, surely - that's the whole problem?
When I set up /var/www/svn as above, I get AVC messages like:
audit(1100636258.341:0): avc: denied { write } for pid=21318 exe=/usr/sbin/httpd name=__db.001 dev=hda2 ino=3169309 scontext=root:system_r:httpd_t tcontext=root:object_r:httpd_sys_content_t tclass=file
joe
Joe Orton wrote:
On Tue, Nov 16, 2004 at 01:56:56PM -0500, Colin Walters wrote:
On Tue, 2004-11-16 at 13:21 +0000, Joe Orton wrote:
I think one thing that would help would be making the sets of example httpd module configurations self-documentating w.r.t. SELinux for some of the modules.
It would be nice to go through more possible configurations and try them; so far we've only done a few.
I'll try to go through more of the modules in /etc/httpd/conf.d/*.conf.
So for instance, how do I get Subversion/mod_dav_svn working with an SELinux-enabled httpd? Can we make it such that an SVN repos is as easy to set up as:
# cd /src/svn # svnadmin create mystuff # vi /etc/httpd/conf.d/subversion.conf
- uncomment the defaults?
Well, given that the path /src/ doesn't exist by default right now, we can't ensure it's labeled correctly out of the box. Maybe we could have default configuration use /var/www/.
That would work too.
A more generic example would be if we provide a /srv/www directory or something to which the httpd domain is allowed read+write access by default; somewhere to put the PHP webapps.
/srv/www should probably be just be labeled the same as /var/www by default. Since the default label is httpd_sys_content_t, which in the default boolean set httpd_t is allowed to write to, PHP apps storing e.g. a SQLite database there should work.
httpd_t *cannot* write to anything labelled with httpd_sys_content_t by default, surely - that's the whole problem?
When I set up /var/www/svn as above, I get AVC messages like:
audit(1100636258.341:0): avc: denied { write } for pid=21318 exe=/usr/sbin/httpd name=__db.001 dev=hda2 ino=3169309 scontext=root:system_r:httpd_t tcontext=root:object_r:httpd_sys_content_t tclass=file
joe
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
Policy has been updated to allow this. Please update to selinux-policy-targeted-1.17.30-2.26 or greater.
On Tue, Nov 16, 2004 at 03:35:49PM -0500, Daniel J Walsh wrote:
Joe Orton wrote:
httpd_t *cannot* write to anything labelled with httpd_sys_content_t by default, surely - that's the whole problem?
When I set up /var/www/svn as above, I get AVC messages like:
audit(1100636258.341:0): avc: denied { write } for pid=21318 exe=/usr/sbin/httpd name=__db.001 dev=hda2 ino=3169309 scontext=root:system_r:httpd_t tcontext=root:object_r:httpd_sys_content_t tclass=file
Policy has been updated to allow this. Please update to selinux-policy-targeted-1.17.30-2.26 or greater.
The same using a fresh Raw Hide install from yesterday, selinux-policy-targeted-1.19.1-9:
audit(1100690797.204:0): avc: denied { write } for pid=2388 exe=/usr/sbin/httpd name=__db.001 dev=md0 ino=1194146 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:httpd_sys_content_t tclass=file
joe
Joe Orton wrote:
On Tue, Nov 16, 2004 at 03:35:49PM -0500, Daniel J Walsh wrote:
Joe Orton wrote:
httpd_t *cannot* write to anything labelled with httpd_sys_content_t by default, surely - that's the whole problem?
When I set up /var/www/svn as above, I get AVC messages like:
audit(1100636258.341:0): avc: denied { write } for pid=21318 exe=/usr/sbin/httpd name=__db.001 dev=hda2 ino=3169309 scontext=root:system_r:httpd_t tcontext=root:object_r:httpd_sys_content_t tclass=file
Policy has been updated to allow this. Please update to selinux-policy-targeted-1.17.30-2.26 or greater.
The same using a fresh Raw Hide install from yesterday, selinux-policy-targeted-1.19.1-9:
audit(1100690797.204:0): avc: denied { write } for pid=2388 exe=/usr/sbin/httpd name=__db.001 dev=md0 ino=1194146 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:httpd_sys_content_t tclass=file
If you label svn file httpd_sys_script_rw_t it should work, but this does expose a bug in httpd_unified boolean, that I fixed in selinux-policy-targeted-1.19.1-12 and selinux-policy-targeted-1.17.30-2.31
joe
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
Daniel J Walsh dwalsh@redhat.com wrote:
audit(1100636258.341:0): avc: denied { write } for pid=21318 exe=/usr/sbin/httpd name=__db.001 dev=hda2 ino=3169309 scontext=root:system_r:httpd_t tcontext=root:object_r:httpd_sys_content_t tclass=file
Policy has been updated to allow this. Please update to selinux-policy-targeted-1.17.30-2.26 or greater.
I looked selinux-policy-strict|targeted-sources-1.19.4-1, and found following statements. if (httpd_enable_cgi && httpd_unified ) { ... allow httpd_t httpdcontent:file { create ioctl read getattr lock write setattr append link unlink rename }; .. }
I think it is allowing too much. It will be hard for users to guess "httpd_unified" means "allowing httpd fullaccess to all contents".
Separete boolean like "httpd_content_writable" should be prepared. # I am not sure the name is good..
And I think, like "httpd_sys_script_rw_t", "httpd_rw_t" would be useful in using PHP(such as wiki,xoops). Users can allow write permission only by modifying types.
Please look at attached diffs.
--- Yuichi Nakamura Japan SELinux Users Group(JSELUG) http://www.selinux.gr.jp/
On Sun, 2004-11-21 at 18:11 -0500, Yuichi Nakamura wrote:
Daniel J Walsh dwalsh@redhat.com wrote:
audit(1100636258.341:0): avc: denied { write } for pid=21318 exe=/usr/sbin/httpd name=__db.001 dev=hda2 ino=3169309 scontext=root:system_r:httpd_t tcontext=root:object_r:httpd_sys_content_t tclass=file
Policy has been updated to allow this. Please update to selinux-policy-targeted-1.17.30-2.26 or greater.
I looked selinux-policy-strict|targeted-sources-1.19.4-1, and found following statements. if (httpd_enable_cgi && httpd_unified ) { ... allow httpd_t httpdcontent:file { create ioctl read getattr lock write setattr append link unlink rename }; .. }
I think it is allowing too much.
You think the boolean should not exist? Or just think it should grant fewer permissions?
It will be hard for users to guess "httpd_unified" means "allowing httpd fullaccess to all contents".
My hope is that anyone who wants to do SELinux/Apache work on Fedora will either 1) Read the Fedora Apache/SELinux guide, where this is documented 2) Understand enough about SELinux to understand what the union of a permission set means.
Separete boolean like "httpd_content_writable" should be prepared. # I am not sure the name is good..
A different boolean? I don't think that's all that useful because most users will either:
1) Want CGI scripts to execute as well 2) Understand enough about labeling to turn the boolean off and label things with the stronger types (httpd_sys_script_exec_t, httpd_sys_script_rw_t).
And I think, like "httpd_sys_script_rw_t", "httpd_rw_t" would be useful in using PHP(such as wiki,xoops). Users can allow write permission only by modifying types.
Well, this is certainly arguable, but my feeling is that the current default Fedora Apache policy configuration hits a kind of sweet spot where a lot of things should be able to work out of the box, without users having to necessarily understand "chcon". If every user, even one just serving static files or doing simple CGI scripts had to learn about relabeling, we might have more users turning the Apache enforcement off.
In the future though, once FC3 and experience with SELinux has percolated into the experience of the general community, we have better documentation, etc., we could consider turning the httpd_unified boolean off by default for FC4.
Colin Walters wrote:
On Sun, 2004-11-21 at 18:11 -0500, Yuichi Nakamura wrote:
Daniel J Walsh dwalsh@redhat.com wrote:
audit(1100636258.341:0): avc: denied { write } for pid=21318 exe=/usr/sbin/httpd name=__db.001 dev=hda2 ino=3169309 scontext=root:system_r:httpd_t tcontext=root:object_r:httpd_sys_content_t tclass=file
Policy has been updated to allow this. Please update to selinux-policy-targeted-1.17.30-2.26 or greater.
I looked selinux-policy-strict|targeted-sources-1.19.4-1, and found following statements. if (httpd_enable_cgi && httpd_unified ) { ... allow httpd_t httpdcontent:file { create ioctl read getattr lock write setattr append link unlink rename }; .. }
I think it is allowing too much.
You think the boolean should not exist? Or just think it should grant fewer permissions?
I think it should grant fewer permissions. Why httpd_t should write all contents in httpd_unified ?
In my understanding, "httpd_unified" means unifying domain transition's entry points of CGI. So, I feel that allowing httpd_t write permission to all contents is out of scope of httpd_unified.
--- Yuichi Nakamura Japan SELinux Users Group(JSELUG) http://www.selinux.gr.jp/
Our view of httpd_unified, is allow all httpd executables to have full access to all httpd content. So we are locking up apache to only change apache, but not preventing parts of apache from effecting other parts.
Daniel J Walsh wrote:
Our view of httpd_unified, is allow all httpd executables to have full access to all httpd content. So we are locking up apache to only change apache, but not preventing parts of apache from effecting other parts.
Thank you. I think it is a big change, notifying users meaning of httpd_unified will become more important.
On Mon, 2004-11-22 at 17:37 -0500, Daniel J Walsh wrote:
Our view of httpd_unified, is allow all httpd executables to have full access to all httpd content.
Hm. Well, this changes the scenarios in the Apache guide. The guide had assumed that if you turned off httpd_enable_cgi, then httpd_t couldn't change any files in the static file serving case. That's not true if httpd_unified stays the way it is.
I guess what's kind of throwing a wrench into this whole thing is PHP, since it runs in-process. So broadly there are two cases:
1) Without PHP/mod_python/etc., but using specific CGI scripts 2) With PHP/mod_python/etc.
Perhaps then what we want is a boolean to distinguish between these cases, say httpd_builtin_scripting. When httpd_builtin_scripting is enabled, we grant to httpd_t all the permissions that we were granting to CGI scripts. We keep httpd_unified, and it means the same thing it meant before: that httpd_sys_content_t is equivalent to httpd_sys_script_rw_t and httpd_sys_script_exec_t.
Then if you enable both httpd_builtin_scripting and httpd_unified, your Apache setup will likely work with most crazy PHP apps. They'll be able to read/write all of the content.
The case of static files and external CGI scripts works with httpd_unified enabled and httpd_builtin_scripting disabled.
And finally, the static file serving case works well with httpd_builtin_scripting and httpd_enable_cgi disabled.
Does that make sense?
Incidentally, why do we have httpd_php_t? It looks rather vestigial.
On Mon, 2004-11-22 at 17:30 -0500, Yuichi Nakamura wrote:
I think it should grant fewer permissions. Why httpd_t should write all contents in httpd_unified ?
Ah, I see what you're saying now. Right. Dan added that recently for PHP scripts, I believe.
So, I feel that allowing httpd_t write permission to all contents is out of scope of httpd_unified.
I agree now. Conceptually they are separate things. A new boolean like httpd_content_writable sounds good to me. Sorry about misunderstanding you originally.
What do you think, Dan?
On Mon, 2004-11-22 at 17:59 -0500, Colin Walters wrote:
On Mon, 2004-11-22 at 17:30 -0500, Yuichi Nakamura wrote:
I think it should grant fewer permissions. Why httpd_t should write all contents in httpd_unified ?
Ah, I see what you're saying now. Right. Dan added that recently for PHP scripts, I believe.
So, I feel that allowing httpd_t write permission to all contents is out of scope of httpd_unified.
I agree now. Conceptually they are separate things. A new boolean like httpd_content_writable sounds good to me. Sorry about misunderstanding you originally.
Maybe "httpd_can_write_content" to give it a more active name.
On Mon, Nov 22, 2004 at 05:59:10PM -0500, Colin Walters wrote:
On Mon, 2004-11-22 at 17:30 -0500, Yuichi Nakamura wrote:
I think it should grant fewer permissions. Why httpd_t should write all contents in httpd_unified ?
Ah, I see what you're saying now. Right. Dan added that recently for PHP scripts, I believe.
So, I feel that allowing httpd_t write permission to all contents is out of scope of httpd_unified.
I agree now. Conceptually they are separate things. A new boolean like httpd_content_writable sounds good to me. Sorry about misunderstanding you originally.
But this is boolean is going to be on by default?
I'm going to add this text to /etc/httpd/conf.d/subversion.conf since it (currently :) works out-of-the-box: is the terminology "labelled with a context" correct?
# # Example configuration to enable HTTP access for a directory # containing Subversion repositories, "/var/www/svn". Each repository # must be readable and writable by the 'apache' user. Note that if # SELinux is enabled, the repositories must be labelled with a context # which httpd can write to; this will happen by default for # directories created in /var/www. #
On Tue, 2004-11-23 at 07:48, Joe Orton wrote:
I'm going to add this text to /etc/httpd/conf.d/subversion.conf since it (currently :) works out-of-the-box: is the terminology "labelled with a context" correct?
Yes.
# # Example configuration to enable HTTP access for a directory # containing Subversion repositories, "/var/www/svn". Each repository # must be readable and writable by the 'apache' user. Note that if # SELinux is enabled, the repositories must be labelled with a context # which httpd can write to; this will happen by default for # directories created in /var/www. #
Do you want to consider what to do if a user has an existing SVN repository that they want to drop into /var/www? If the directory already has SELinux xattrs and you mv or cp it to the location, it will have the wrong label.
A simple 'restorecon -R /var/www' will take care of this, recursively giving /var/www/svn the parent context.
- Karsten
Joe Orton wrote:
I'm going to add this text to /etc/httpd/conf.d/subversion.conf since it (currently :) works out-of-the-box: is the terminology "labelled with a context" correct? # # Example configuration to enable HTTP access for a directory # containing Subversion repositories, "/var/www/svn". Each repository # must be readable and writable by the 'apache' user. Note that if # SELinux is enabled, the repositories must be labelled with a context # which httpd can write to; this will happen by default for # directories created in /var/www. #
As far as I know, context writable by httpd is not prepared. So I think type like httpd_rw_t I suggested before will be necessary.
--- Yuichi Nakamura Japan SELinux Users Group(JSELUG) http://www.selinux.gr.jp/
On Wed, Nov 24, 2004 at 08:58:04PM -0500, Yuichi Nakamura wrote:
Joe Orton wrote:
I'm going to add this text to /etc/httpd/conf.d/subversion.conf since it (currently :) works out-of-the-box: is the terminology "labelled with a context" correct? # # Example configuration to enable HTTP access for a directory # containing Subversion repositories, "/var/www/svn". Each repository # must be readable and writable by the 'apache' user. Note that if # SELinux is enabled, the repositories must be labelled with a context # which httpd can write to; this will happen by default for # directories created in /var/www. #
As far as I know, context writable by httpd is not prepared. So I think type like httpd_rw_t I suggested before will be necessary.
With the current policy, system_u:object_r:httpd_sys_content_t *is* writable by httpd_t by default. If this changes or is going to change this text will need to be updated, yup.
joe
On Mon, 22 Nov 2004 13:05:53 EST, Colin Walters said:
It will be hard for users to guess "httpd_unified" means "allowing httpd fullaccess to all contents".
My hope is that anyone who wants to do SELinux/Apache work on Fedora will either
- Read the Fedora Apache/SELinux guide, where this is documented
- Understand enough about SELinux to understand what the union of a
permission set means.
Idiot me - at first glance, I assumed that 'httpd_unified' was the policy file that allowed for differences in file locations across Fedora/debian/gentoo. ;)
Yes, I know what the union of a permission set is (at least when I've had enough caffeine - but didn't see that "unified" referred to a union of permission sets.... Yuichi is correct - it's not an incredibly intuitive name. And remember that a *lot* of people will be installing SELinux under future Fedora Core and RHEL releases who are *NOT* SELinux experts - they will know "I'm running SELinux, and I have these services, so I need to install the policies they need" - and that's the limit of their in-depth understanding...
On Tue, 2004-11-16 at 12:35, Daniel J Walsh wrote:
Joe Orton wrote:
httpd_t *cannot* write to anything labelled with httpd_sys_content_t by default, surely - that's the whole problem?
Policy has been updated to allow this. Please update to selinux-policy-targeted-1.17.30-2.26 or greater.
I can't find this allow rule in 1.17.30-2.34. I've used apol direct and transitive information flow analysis and good ol' grep to no avail. Before I post a very long message detailing everything I did, can someone tell me how httpd_t has gained write allow for httpd_sys_content_t? FWIW, I finally set the boolean in apache.te and recompiled policy, but still can't find the write.
thx - Karsten
On Sun, 2004-11-28 at 08:23 -0800, Karsten Wade wrote:
On Tue, 2004-11-16 at 12:35, Daniel J Walsh wrote:
Joe Orton wrote:
httpd_t *cannot* write to anything labelled with
httpd_sys_content_t by
default, surely - that's the whole problem?
Policy has been updated to allow this. Please update to selinux-policy-targeted-1.17.30-2.26 or greater.
I can't find this allow rule in 1.17.30-2.34. I've used apol direct and transitive information flow analysis and good ol' grep to no avail. Before I post a very long message detailing everything I did, can someone tell me how httpd_t has gained write allow for httpd_sys_content_t? FWIW, I finally set the boolean in apache.te and recompiled policy, but still can't find the write.
It's this section:
if (httpd_enable_cgi && httpd_unified ifdef(`targeted_policy', ` && ! httpd_disable_trans')) { ifelse($1, sys, ` domain_auto_trans(httpd_t, httpdcontent, httpd_sys_script_t) domain_auto_trans(httpd_suexec_t, httpdcontent, httpd_sys_script_t) domain_auto_trans(sysadm_t, httpdcontent, httpd_sys_script_t) create_dir_file(httpd_t, httpdcontent) ', ` can_exec(httpd_$1_script_t, httpdcontent ) domain_auto_trans($1_t, httpdcontent, httpd_$1_script_t) ') create_dir_file(httpd_$1_script_t, httpdcontent) }
Specifically: create_dir_file(httpd_, httpdcontent)
httpdcontent is an attribute that all of the various httpd types such as httpd_sys_content_t has.
Karsten Wade wrote:
httpd_t *cannot* write to anything labelled with httpd_sys_content_t by default, surely - that's the whole problem?
I can't find this allow rule in 1.17.30-2.34. I've used apol direct and transitive information flow analysis and good ol' grep to no avail. Before I post a very long message detailing everything I did, can someone tell me how httpd_t has gained write allow for httpd_sys_content_t? FWIW, I finally set the boolean in apache.te and recompiled policy, but still can't find the write.
It is in macros/program/apache_macros.te. I pick up related part in following. --- 113 if (httpd_enable_cgi) && (httpd_unified) ifdef(`targeted_policy', ` && ! (httpd_disable_trans)') { 114 ifelse($1, sys, ` 115 domain_auto_trans(httpd_t, httpdcontent, httpd_sys_script_t) 116 domain_auto_trans(httpd_suexec_t, httpdcontent, httpd_sys_script_t) 117 domain_auto_trans(sysadm_t, httpdcontent, httpd_sys_script_t) 118 create_dir_file(httpd_t, httpdcontent) 119 ', ` 120 create_dir_file(httpd_$1_script_t, httpdcontent) 121 can_exec(httpd_$1_script_t, httpdcontent ) 122 domain_auto_trans($1_t, httpdcontent, httpd_$1_script_t) 123 ') 124 } --- Line 118 and line 120 are what you are looking for.
In policy.conf I found 3 rules, too. type httpd_sys_content_t, file_type, homedirfile, httpdcontent, sysadmfile; allow httpd_t httpdcontent:dir { create read getattr lock setattr ioctl link unlink rename search add_name remove_name reparent write rmdir }; allow httpd_t httpdcontent:file { create ioctl read getattr lock write setattr append link unlink rename };
I can't find this allow rule in 1.17.30-2.34. I've used apol direct and transitive information flow analysis and good ol' grep to no avail.
I tried apol now, but I could not find the rule, either. apol information flow may not support attributes or booleans, but I am not sure.
--- Yuichi Nakamura Japan SELinux Users Group(JSELUG) http://www.selinux.gr.jp/
On Sun, 2004-11-28 at 12:10, Yuichi Nakamura wrote:
I can't find this allow rule in 1.17.30-2.34. I've used apol direct and transitive information flow analysis and good ol' grep to no avail.
I tried apol now, but I could not find the rule, either. apol information flow may not support attributes or booleans, but I am not sure.
This turned out to be a mistake in the way I was using apol.
First, all the necessary Booleans have to be set (I had missed enabling httpd_enable_cgi). For analyzing policy.conf, the allow rule can be found using Policy Rules > TE Rules, enabling Include Indirect Matches, with the Source Type set to httpd_t and Target Type set to httpd_sys_content_t:
(5597) allow httpd_t httpdcontent : file { create ioctl read getattr lock write setattr append link unlink rename };
That is right at the top of the list. The (5597) is a link directly to the line in policy.conf (in another tab).
Doing the same search on the binary policy file will actually expand httpdcontent into httpd_sys_content_t.
I also could have found it by leaving the Booleans alone and disabling "Only search for enabled rules". The information flow analysis (Analysis tab) requires the Booleans to be set, but they also find the rule.
- Karsten
selinux@lists.fedoraproject.org
-
Colin Walters -
Daniel J Walsh -
Joe Orton -
Karsten Wade -
Valdis.Kletnieks＠vt.edu -
Yuichi Nakamura