10:25 p.m.
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.
--
Florin Andrei
http://florin.myip.org/
1:29 a.m.
On Thursday 02 June 2005 13:25, Florin Andrei <florin(a)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.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
2:27 a.m.
On Fri, 2005-06-03 at 16:29 +1000, Russell Coker wrote:
On Thursday 02 June 2005 13:25, Florin Andrei
<florin(a)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?
--
Florin Andrei
http://florin.myip.org/
2:46 a.m.
On Friday 03 June 2005 17:27, Florin Andrei <florin(a)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(a)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.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
12:16 p.m.
On Fri, 2005-06-03 at 17:46 +1000, Russell Coker wrote:
On Friday 03 June 2005 17:27, Florin Andrei
<florin(a)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...
--
Florin Andrei
http://florin.myip.org/
1:08 a.m.
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(a)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...
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...
--
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
Red Hat SELinux Guide
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/
3:21 p.m.
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(a)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
--
6897
days inactive
6902
days old
selinux@lists.fedoraproject.org
6 comments
4 participants
participants (4)
-
Daniel J Walsh -
Florin Andrei -
Karsten Wade -
Russell Coker