Any guidelines for changing the SELinux config for a system that's controlled over a web interface running in Apache? The interface is supposed to do things like: stop/start services, change network settings, etc.
On Thursday 02 June 2005 13:25, Florin Andrei florin@andrei.myip.org wrote:
Any guidelines for changing the SELinux config for a system that's controlled over a web interface running in Apache? The interface is supposed to do things like: stop/start services, change network settings, etc.
Probably the easiest solution will be to have Apache or the CGI-BIN script in question running unconfined.
On Fri, 2005-06-03 at 16:29 +1000, Russell Coker wrote:
On Thursday 02 June 2005 13:25, Florin Andrei florin@andrei.myip.org wrote:
Any guidelines for changing the SELinux config for a system that's controlled over a web interface running in Apache? The interface is supposed to do things like: stop/start services, change network settings, etc.
Probably the easiest solution will be to have Apache or the CGI-BIN script in question running unconfined.
True, but I'd like to avoid that.
Is there any tutorial that describes how to use the selinux avc: denied messages to "loosen up" the policy? I'd imagine that by exercising the daemon in all ways possible, and keeping an eye on syslog at the same time, I should be able to figure out what needs to be permitted in the policy, right? Should be fairly straightforward once the details are comprehended. Any guidelines/howto/cookbook on the subject?
On Friday 03 June 2005 17:27, Florin Andrei florin@andrei.myip.org wrote:
On Fri, 2005-06-03 at 16:29 +1000, Russell Coker wrote:
On Thursday 02 June 2005 13:25, Florin Andrei florin@andrei.myip.org
wrote:
Any guidelines for changing the SELinux config for a system that's controlled over a web interface running in Apache? The interface is supposed to do things like: stop/start services, change network settings, etc.
Probably the easiest solution will be to have Apache or the CGI-BIN script in question running unconfined.
True, but I'd like to avoid that.
Why?
If Apache can change system configuration files and restart daemons then what's the point of trying to restrict it? Using Apache to configure the system to boot without SE Linux enabled should be easy enough.
Is there any tutorial that describes how to use the selinux avc: denied messages to "loosen up" the policy?
No. The problem you face is how to change the labels on some file so that Apache can write to them but not grant Apache write to too many things. If your requirement is "control everything over the web" then this may not be a solvable problem.
I'd imagine that by exercising the daemon in all ways possible, and keeping an eye on syslog at the same time, I should be able to figure out what needs to be permitted in the policy, right?
Correct.
On Fri, 2005-06-03 at 17:46 +1000, Russell Coker wrote:
On Friday 03 June 2005 17:27, Florin Andrei florin@andrei.myip.org wrote:
On Fri, 2005-06-03 at 16:29 +1000, Russell Coker wrote:
Probably the easiest solution will be to have Apache or the CGI-BIN script in question running unconfined.
True, but I'd like to avoid that.
If Apache can change system configuration files and restart daemons then what's the point of trying to restrict it? Using Apache to configure the system to boot without SE Linux enabled should be easy enough.
It's not supposed to change everything. The system will be a "black box" to the users who have access to it solely through the Web interface, but that interface is not all-powerful. Some daemons can be tweaked, some system parameters can be changed, but the interface will not and should not have discretionary powers.
I'd like to retain some of the protection offered by SELinux.
The problem you face is how to change the labels on some file so that Apache can write to them but not grant Apache write to too many things. If your requirement is "control everything over the web" then this may not be a solvable problem.
Ok, I see. My mistake - the interface doesn't control everything.
I'm thinking about this: how about I leave the policy alone, create a small daemon (in Perl, whatever) that's listening on a Unix socket, then the Web interface is just passing the commands to the daemon. The daemon compares them to a list of "known good commands", maybe makes some other verifications, then goes ahead and executes the commands. This way I retain the original tight policy, plus I get a supplemental level of intelligence in validating what gets sent to the system via the interface.
I dunno, this might be a method that would be interesting for more people using selinux that want to keep selinux but still be able to have a deeper control over the system.
I'd imagine that by exercising the daemon in all ways possible, and keeping an eye on syslog at the same time, I should be able to figure out what needs to be permitted in the policy, right?
Correct.
<sigh> I wish there was a concrete example somewhere on how to do that. It's not like SELinux doesn't have any docs at all but... So many things to do, so little time...
On Fri, 2005-06-03 at 10:16 -0700, Florin Andrei wrote:
On Fri, 2005-06-03 at 17:46 +1000, Russell Coker wrote:
On Friday 03 June 2005 17:27, Florin Andrei florin@andrei.myip.org wrote:
I'd imagine that by exercising the daemon in all ways possible, and keeping an eye on syslog at the same time, I should be able to figure out what needs to be permitted in the policy, right?
Correct.
<sigh> I wish there was a concrete example somewhere on how to do that. It's not like SELinux doesn't have any docs at all but... So many things to do, so little time...
You might have seen this, or not:
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/se...
It's very generic and high-level. I'm very interested in real world experiences trying to use those how-to instructions. Other methodologies and experiences are also interesting. You can file a bugzilla report[1] with any details you want to share. This is an area of the SELinux Guide that people are asking for improvement on, and it would be nice to have more concrete details to work from.
- Karsten
[1] Follow the directions here:
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/s1...
Florin Andrei wrote:
On Fri, 2005-06-03 at 17:46 +1000, Russell Coker wrote:
On Friday 03 June 2005 17:27, Florin Andrei florin@andrei.myip.org wrote:
On Fri, 2005-06-03 at 16:29 +1000, Russell Coker wrote:
Probably the easiest solution will be to have Apache or the CGI-BIN script in question running unconfined.
True, but I'd like to avoid that.
If Apache can change system configuration files and restart daemons then what's the point of trying to restrict it? Using Apache to configure the system to boot without SE Linux enabled should be easy enough.
It's not supposed to change everything. The system will be a "black box" to the users who have access to it solely through the Web interface, but that interface is not all-powerful. Some daemons can be tweaked, some system parameters can be changed, but the interface will not and should not have discretionary powers.
I'd like to retain some of the protection offered by SELinux.
The problem you face is how to change the labels on some file so that Apache can write to them but not grant Apache write to too many things. If your requirement is "control everything over the web" then this may not be a solvable problem.
Ok, I see. My mistake - the interface doesn't control everything.
I'm thinking about this: how about I leave the policy alone, create a small daemon (in Perl, whatever) that's listening on a Unix socket, then the Web interface is just passing the commands to the daemon. The daemon compares them to a list of "known good commands", maybe makes some other verifications, then goes ahead and executes the commands. This way I retain the original tight policy, plus I get a supplemental level of intelligence in validating what gets sent to the system via the interface.
I dunno, this might be a method that would be interesting for more people using selinux that want to keep selinux but still be able to have a deeper control over the system.
I'd imagine that by exercising the daemon in all ways possible, and keeping an eye on syslog at the same time, I should be able to figure out what needs to be permitted in the policy, right?
Correct.
<sigh> I wish there was a concrete example somewhere on how to do that. It's not like SELinux doesn't have any docs at all but... So many things to do, so little time...
You can begin defining the policy via
apache_domain.
After installing selinux-policy-targeted-sources I would start out by creating a te file.
cd /etc/selinux/targetd/src/policy echo apache_domain(mycgi) >> domains/program/mycgi.te echo "/var/www/cgi-bin/mycgi -- system_u:object_r:httpd_mycgi_script_exec_t" > file_contexts/program/mycgi.te make load restorecon /var/www/cgi-bin/mycgi setenforce 0
Start using the mycgi script file. Gather the avc messages and start using audit2allow to generate rules for the script. Lather; Rinse; Repeat.
Dan
selinux@lists.fedoraproject.org
-
Daniel J Walsh -
Florin Andrei -
Karsten Wade -
Russell Coker