Qustion regarding: selinux / perl-cgi / iptables
 

Hi, I was wondering if anyone has information or can direct me to more
details on the following:

I have been using a perl cgi script on a personal web-server of mine
to control access to SSH.
Essentially, it is a knock-knock system. I would go to a specific URL
with the cgi, enter some information, and the perl script would add my
ip address to the allowed list for SSH in the fire-wall.

I have been working on learning the details with SElinux, and trying
to come up with some rules to allow the script to work correctly.
There appears to be some kind of conflict either related to the script
itself, or being run through httpd and getting access to the IPTables
command tools.

The CGI script (written in perl) is SUID root.
Httpd runs the script.
The script will run the iptables command line tools to examine the
table (to see if the ip address is already allowed), and also to add a
new ip address to the allowed list.

My current method of trying to create the appropriate policy is to
continue testing the cgi-script, watching the audit log, and running
audit2allow on the selected audit messages.

My current policy is:

...
require {
type modules_conf_t;
type modules_dep_t;
type sysctl_modprobe_t;
type boot_t;
type httpd_sys_script_t;
type modules_object_t;
class capability net_raw;
class dir { getattr search };
class file { read getattr };
class rawip_socket { getopt create };
}

#============= httpd_sys_script_t ==============
allow httpd_sys_script_t boot_t:dir getattr;
allow httpd_sys_script_t modules_conf_t:file { read getattr };
allow httpd_sys_script_t modules_dep_t:file read;
allow httpd_sys_script_t modules_object_t:dir search;
allow httpd_sys_script_t self:capability net_raw;
allow httpd_sys_script_t self:rawip_socket { getopt create };
...

So, my question boils down to this:
(I'm running Fedora Core 7)
Do I just continue running the audit2allow repeatedly to create a
policy to do what I want?

Is there a better way to solve this problem? I am concerned that just
creating a policy to allow my script to run will create other more
substantial holes.

I am also open to creating a tool to update my iptables some other
way. Maybe perl-cgi is not the best method?

Thanks in advance for any information!

- Paul

--
Paul McAvoy <paulmcav@queda.net>
http://www.queda.net

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

Qustion regarding: selinux / perl-cgi / iptables
 

Paul McAvoy wrote:

Hi, I was wondering if anyone has information or can direct me to more
details on the following:

I have been using a perl cgi script on a personal web-server of mine
to control access to SSH.
Essentially, it is a knock-knock system. I would go to a specific URL
with the cgi, enter some information, and the perl script would add my
ip address to the allowed list for SSH in the fire-wall.

I have been working on learning the details with SElinux, and trying
to come up with some rules to allow the script to work correctly.
There appears to be some kind of conflict either related to the script
itself, or being run through httpd and getting access to the IPTables
command tools.

The CGI script (written in perl) is SUID root.
Httpd runs the script.
The script will run the iptables command line tools to examine the
table (to see if the ip address is already allowed), and also to add a
new ip address to the allowed list.

My current method of trying to create the appropriate policy is to
continue testing the cgi-script, watching the audit log, and running
audit2allow on the selected audit messages.

My current policy is:

...
require {
type modules_conf_t;
type modules_dep_t;
type sysctl_modprobe_t;
type boot_t;
type httpd_sys_script_t;
type modules_object_t;
class capability net_raw;
class dir { getattr search };
class file { read getattr };
class rawip_socket { getopt create };
}

#============= httpd_sys_script_t ==============
allow httpd_sys_script_t boot_t:dir getattr;
allow httpd_sys_script_t modules_conf_t:file { read getattr };
allow httpd_sys_script_t modules_dep_t:file read;
allow httpd_sys_script_t modules_object_t:dir search;
allow httpd_sys_script_t self:capability net_raw;
allow httpd_sys_script_t self:rawip_socket { getopt create };
...

So, my question boils down to this:
(I'm running Fedora Core 7)
Do I just continue running the audit2allow repeatedly to create a
policy to do what I want?

Is there a better way to solve this problem? I am concerned that just
creating a policy to allow my script to run will create other more
substantial holes.

I am also open to creating a tool to update my iptables some other
way. Maybe perl-cgi is not the best method?

Thanks in advance for any information!


The quickest fix for this is probably to relabel your script as
httpd_unconfined_script_exec_t, which would run that particular script
unconfined by SELinux without opening up all sorts of extra avenues for
all the other scripts on your system.


Longer term I'd be inclined to write a specific policy for this script
using the apache_content_template, but that's a bigger job.


Paul.

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

Qustion regarding: selinux / perl-cgi / iptables
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Howarth wrote:
> Paul McAvoy wrote:
>> Hi, I was wondering if anyone has information or can direct me to more
>> details on the following:
>>
>> I have been using a perl cgi script on a personal web-server of mine
>> to control access to SSH.
>> Essentially, it is a knock-knock system. I would go to a specific URL
>> with the cgi, enter some information, and the perl script would add my
>> ip address to the allowed list for SSH in the fire-wall.
>>
>> I have been working on learning the details with SElinux, and trying
>> to come up with some rules to allow the script to work correctly.
>> There appears to be some kind of conflict either related to the script
>> itself, or being run through httpd and getting access to the IPTables
>> command tools.
>>
>> The CGI script (written in perl) is SUID root.
>> Httpd runs the script.
>> The script will run the iptables command line tools to examine the
>> table (to see if the ip address is already allowed), and also to add a
>> new ip address to the allowed list.
>>
>> My current method of trying to create the appropriate policy is to
>> continue testing the cgi-script, watching the audit log, and running
>> audit2allow on the selected audit messages.
>>
>> My current policy is:
>>
>> ...
>> require {
>> type modules_conf_t;
>> type modules_dep_t;
>> type sysctl_modprobe_t;
>> type boot_t;
>> type httpd_sys_script_t;
>> type modules_object_t;
>> class capability net_raw;
>> class dir { getattr search };
>> class file { read getattr };
>> class rawip_socket { getopt create };
>> }
>>
>> #============= httpd_sys_script_t ==============
>> allow httpd_sys_script_t boot_t:dir getattr;
>> allow httpd_sys_script_t modules_conf_t:file { read getattr };
>> allow httpd_sys_script_t modules_dep_t:file read;
>> allow httpd_sys_script_t modules_object_t:dir search;
>> allow httpd_sys_script_t self:capability net_raw;
>> allow httpd_sys_script_t self:rawip_socket { getopt create };
>> ...
>>
>> So, my question boils down to this:
>> (I'm running Fedora Core 7)
>> Do I just continue running the audit2allow repeatedly to create a
>> policy to do what I want?
>>
>> Is there a better way to solve this problem? I am concerned that just
>> creating a policy to allow my script to run will create other more
>> substantial holes.
>>
>> I am also open to creating a tool to update my iptables some other
>> way. Maybe perl-cgi is not the best method?
>>
>> Thanks in advance for any information!
>
> The quickest fix for this is probably to relabel your script as
> httpd_unconfined_script_exec_t, which would run that particular script
> unconfined by SELinux without opening up all sorts of extra avenues for
> all the other scripts on your system.
>
> Longer term I'd be inclined to write a specific policy for this script
> using the apache_content_template, but that's a bigger job.
>
> Paul.
>
> --
> fedora-selinux-list mailing list
> fedora-selinux-list@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
You could fairly simply write a policy for this script using

system-config-selinux/polgengui

If you go under the modules section of system-config-selinux and select
new. It will start a Wizard to help you write the policy. When the
policy is generated, you can add these specific rules without chaning
the behaviour of how all other http scripts would work.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHVCQUrlYvE4MpobMRAguLAJ9+tgtsfjxT9CPnicaIIp lmxrXywACgwA5D
HjBc7+6fhEES0KsDh6i0gmo=
=4hyS
-----END PGP SIGNATURE-----

--
fedora-selinux-list mailing list
fedora-selinux-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list