3:46 a.m.
Paul Howarth wrote:
The simplest fix might be to change the file context of this
particular
CGI script to httpd_unconfined_script_exec_t instead of
httpd_sys_script_t. That would effectively turn off SELinux protection
for that particular script.
The alternative approach of using audit2allow to create a local
policy
to allow these capabilities would turn on these capabilities for *all*
of your CGI scripts, which IMHO would be worse than turning off
protection for just that one script (particularly if that script was
well-audited for security issues).
Ideally it would be easy to create a subclass of CGI scripts and
assign
special capabilities to those (I have a similar issue with FastCGI
scripts that need slightly more capabilities than regular CGI scripts),
but that's beyond me at this moment.
As the script in question can indeed be called well-audited (basically, it
just allows to trigger a certain action by calling another script with
fixed attributes), I have decided to go with httpd_unconfined_script_exec_t.
That did the trick neatly.
Thanks very much,
Jochen
5:27 a.m.
New subject: CGI Script permissions
Jochen Wiedmann wrote:
Paul Howarth wrote:
> The simplest fix might be to change the file context of this particular
> CGI script to httpd_unconfined_script_exec_t instead of
> httpd_sys_script_t. That would effectively turn off SELinux protection
> for that particular script.
>
> The alternative approach of using audit2allow to create a local policy
> to allow these capabilities would turn on these capabilities for *all*
> of your CGI scripts, which IMHO would be worse than turning off
> protection for just that one script (particularly if that script was
> well-audited for security issues).
>
> Ideally it would be easy to create a subclass of CGI scripts and assign
> special capabilities to those (I have a similar issue with FastCGI
> scripts that need slightly more capabilities than regular CGI scripts),
> but that's beyond me at this moment.
>
As the script in question can indeed be called well-audited (basically, it
just allows to trigger a certain action by calling another script with
fixed attributes), I have decided to go with httpd_unconfined_script_exec_t.
That did the trick neatly.
Thanks very much,
Jochen
Another alternative might be to write your own module
Create three files
# cat >> myapache.te << _EOF
policy_module(myapache,1.0.0)
apache_content_template(myapache)
allow httpd_myapache_script_t self:capability setuid;
allow httpd_myapache_script_t self:process setrlimit;
_EOF
echo > myapache.if
# cat >> myapache.te << _EOF
/var/www/cgi-bin/myapache_script --
gen_context(system_u:object_r:httpd_myapache_script_exec_t,s0)
_EOF
Then build a policy module.
make -f /usr/share/selinux/devel/Makefile
semodule -i myapache.pp
restorecon -F -v /var/www/cgi-bin/myapache_script
Then try it out.
Of course you might need additional rules.
--
fedora-selinux-list mailing list
fedora-selinux-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
9:20 a.m.
New subject: CGI Script permissions
Daniel J Walsh wrote:
Jochen Wiedmann wrote:
> Paul Howarth wrote:
>
>
>> The simplest fix might be to change the file context of this particular
>> CGI script to httpd_unconfined_script_exec_t instead of
>> httpd_sys_script_t. That would effectively turn off SELinux protection
>> for that particular script.
>>
>
>
>> The alternative approach of using audit2allow to create a local policy
>> to allow these capabilities would turn on these capabilities for *all*
>> of your CGI scripts, which IMHO would be worse than turning off
>> protection for just that one script (particularly if that script was
>> well-audited for security issues).
>>
>
>
>> Ideally it would be easy to create a subclass of CGI scripts and assign
>> special capabilities to those (I have a similar issue with FastCGI
>> scripts that need slightly more capabilities than regular CGI scripts),
>> but that's beyond me at this moment.
>>
>
> As the script in question can indeed be called well-audited
> (basically, it
> just allows to trigger a certain action by calling another script with
> fixed attributes), I have decided to go with
> httpd_unconfined_script_exec_t.
> That did the trick neatly.
>
> Thanks very much,
>
> Jochen
>
Another alternative might be to write your own module
Create three files
# cat >> myapache.te << _EOF
policy_module(myapache,1.0.0)
apache_content_template(myapache)
allow httpd_myapache_script_t self:capability setuid;
allow httpd_myapache_script_t self:process setrlimit;
_EOF
echo > myapache.if
# cat >> myapache.te << _EOF
That should be myapache.fc
/var/www/cgi-bin/myapache_script --
gen_context(system_u:object_r:httpd_myapache_script_exec_t,s0)
_EOF
Then build a policy module.
make -f /usr/share/selinux/devel/Makefile
semodule -i myapache.pp
restorecon -F -v /var/www/cgi-bin/myapache_script
Then try it out.
Of course you might need additional rules.
I made something similar for my moin wiki running under mod_fcgid:
te file:
policy_module(apache, 0.2.1)
require {
type devpts_t;
type httpd_t;
type httpd_log_t;
type httpd_sys_script_exec_t;
type var_run_t;
};
# ==========================================================
# Create and use httpd_fastcgi_script_t for mod_fcgid apps
# ==========================================================
apache_content_template(fastcgi)
kernel_read_kernel_sysctls(httpd_fastcgi_script_t)
# Allow FastCGI applications to live alongside regular CGI apps
allow httpd_fastcgi_script_t httpd_sys_script_exec_t:dir {
search_dir_perms };
# Allow FastCGI applications to listen for FastCGI requests on their
# sockets and respond to them
allow httpd_fastcgi_script_t httpd_t:unix_stream_socket {
rw_stream_socket_perms };
# FastCGI application doing something to the httpd error log
dontaudit httpd_fastcgi_script_t httpd_log_t:file ioctl;
# Not sure what this is doing (happens when fastcgi scripts start)
dontaudit httpd_t devpts_t:chr_file ioctl;
# mod_fcgid setting attr of its socket dir
allow httpd_t var_run_t:dir setattr;
fc file:
/srv/www/tips/cgi-bin/moin.fcgi --
gen_context(system_u:object_r:httpd_fastcgi_script_exec_t,s0)
/var/www/tips/cgi-bin/moin.fcgi --
gen_context(system_u:object_r:httpd_fastcgi_script_exec_t,s0)
Paul.
1:18 p.m.
New subject: CGI Script permissions
Paul Howarth wrote:
Daniel J Walsh wrote:
> Jochen Wiedmann wrote:
>> Paul Howarth wrote:
>>
>>
>>> The simplest fix might be to change the file context of this
>>> particular
>>> CGI script to httpd_unconfined_script_exec_t instead of
>>> httpd_sys_script_t. That would effectively turn off SELinux protection
>>> for that particular script.
>>>
>>
>>
>>> The alternative approach of using audit2allow to create a local policy
>>> to allow these capabilities would turn on these capabilities for *all*
>>> of your CGI scripts, which IMHO would be worse than turning off
>>> protection for just that one script (particularly if that script was
>>> well-audited for security issues).
>>>
>>
>>
>>> Ideally it would be easy to create a subclass of CGI scripts and
>>> assign
>>> special capabilities to those (I have a similar issue with FastCGI
>>> scripts that need slightly more capabilities than regular CGI
>>> scripts),
>>> but that's beyond me at this moment.
>>>
>>
>> As the script in question can indeed be called well-audited
>> (basically, it
>> just allows to trigger a certain action by calling another script with
>> fixed attributes), I have decided to go with
>> httpd_unconfined_script_exec_t.
>> That did the trick neatly.
>>
>> Thanks very much,
>>
>> Jochen
>>
>
> Another alternative might be to write your own module
>
> Create three files
>
> # cat >> myapache.te << _EOF
> policy_module(myapache,1.0.0)
> apache_content_template(myapache)
> allow httpd_myapache_script_t self:capability setuid;
> allow httpd_myapache_script_t self:process setrlimit;
> _EOF
>
> echo > myapache.if
>
> # cat >> myapache.te << _EOF
That should be myapache.fc
> /var/www/cgi-bin/myapache_script --
> gen_context(system_u:object_r:httpd_myapache_script_exec_t,s0)
> _EOF
>
> Then build a policy module.
>
> make -f /usr/share/selinux/devel/Makefile
>
> semodule -i myapache.pp
>
> restorecon -F -v /var/www/cgi-bin/myapache_script
>
> Then try it out. Of course you might need additional rules.
I made something similar for my moin wiki running under mod_fcgid:
te file:
policy_module(apache, 0.2.1)
require {
type devpts_t;
type httpd_t;
type httpd_log_t;
type httpd_sys_script_exec_t;
type var_run_t;
};
# ==========================================================
# Create and use httpd_fastcgi_script_t for mod_fcgid apps
# ==========================================================
apache_content_template(fastcgi)
kernel_read_kernel_sysctls(httpd_fastcgi_script_t)
# Allow FastCGI applications to live alongside regular CGI apps
allow httpd_fastcgi_script_t httpd_sys_script_exec_t:dir {
search_dir_perms };
# Allow FastCGI applications to listen for FastCGI requests on their
# sockets and respond to them
allow httpd_fastcgi_script_t httpd_t:unix_stream_socket {
rw_stream_socket_perms };
# FastCGI application doing something to the httpd error log
dontaudit httpd_fastcgi_script_t httpd_log_t:file ioctl;
# Not sure what this is doing (happens when fastcgi scripts start)
dontaudit httpd_t devpts_t:chr_file ioctl;
# mod_fcgid setting attr of its socket dir
allow httpd_t var_run_t:dir setattr;
Why not create a context for its socket dir so
you don't need this for
var_run?
fc file:
/srv/www/tips/cgi-bin/moin.fcgi --
gen_context(system_u:object_r:httpd_fastcgi_script_exec_t,s0)
/var/www/tips/cgi-bin/moin.fcgi --
gen_context(system_u:object_r:httpd_fastcgi_script_exec_t,s0)
Paul.
I think it might be a good idea to add this (fastcgi that is) policy to
base. Have you tried to submit it upstream?
2:30 p.m.
New subject: CGI Script permissions
On Fri, 2006-05-26 at 14:18 -0400, Daniel J Walsh wrote:
Paul Howarth wrote:
> I made something similar for my moin wiki running under mod_fcgid:
>
> te file:
>
> policy_module(apache, 0.2.1)
>
> require {
> type devpts_t;
> type httpd_t;
> type httpd_log_t;
> type httpd_sys_script_exec_t;
> type var_run_t;
> };
>
> # ==========================================================
> # Create and use httpd_fastcgi_script_t for mod_fcgid apps
> # ==========================================================
>
> apache_content_template(fastcgi)
> kernel_read_kernel_sysctls(httpd_fastcgi_script_t)
>
> # Allow FastCGI applications to live alongside regular CGI apps
> allow httpd_fastcgi_script_t httpd_sys_script_exec_t:dir {
> search_dir_perms };
>
> # Allow FastCGI applications to listen for FastCGI requests on their
> # sockets and respond to them
> allow httpd_fastcgi_script_t httpd_t:unix_stream_socket {
> rw_stream_socket_perms };
>
> # FastCGI application doing something to the httpd error log
> dontaudit httpd_fastcgi_script_t httpd_log_t:file ioctl;
>
> # Not sure what this is doing (happens when fastcgi scripts start)
> dontaudit httpd_t devpts_t:chr_file ioctl;
>
> # mod_fcgid setting attr of its socket dir
> allow httpd_t var_run_t:dir setattr;
Why not create a context for its socket dir so you don't need this for
var_run?
The obvious type to use would really be httpd_var_run_t rather than
creating a new type (comparing with other users of /var/run). In fact I
think I tried that but it seemed worse than leaving it the default
var_run_t and adding the one allow rule. What would you suggest?
> fc file:
>
> /srv/www/tips/cgi-bin/moin.fcgi --
> gen_context(system_u:object_r:httpd_fastcgi_script_exec_t,s0)
> /var/www/tips/cgi-bin/moin.fcgi --
> gen_context(system_u:object_r:httpd_fastcgi_script_exec_t,s0)
>
> Paul.
I think it might be a good idea to add this (fastcgi that is) policy to
base. Have you tried to submit it upstream?
Not yet; it probably needs more work to add further capabilities, as
I've only use one application with FastCGI myself, and I can see that
httpd_sys_script_t has far more capabilities that I've so far allowed to
httpd_fastcgi_script_t. Perhaps there should be a interface that goes
further than apache_content_template and adds capabilities needed by
most server-side scripts (e.g. the kernel_read_kernel_sysctls from
above), for use in developing custom types like httpd_fastcgi_script_t?
Paul.
2:03 p.m.
New subject: CGI Script permissions
Paul Howarth wrote:
On Fri, 2006-05-26 at 14:18 -0400, Daniel J Walsh wrote:
> Paul Howarth wrote:
>
>> I made something similar for my moin wiki running under mod_fcgid:
>>
>> te file:
>>
>> policy_module(apache, 0.2.1)
>>
>> require {
>> type devpts_t;
>> type httpd_t;
>> type httpd_log_t;
>> type httpd_sys_script_exec_t;
>> type var_run_t;
>> };
>>
>> # ==========================================================
>> # Create and use httpd_fastcgi_script_t for mod_fcgid apps
>> # ==========================================================
>>
>> apache_content_template(fastcgi)
>> kernel_read_kernel_sysctls(httpd_fastcgi_script_t)
>>
>> # Allow FastCGI applications to live alongside regular CGI apps
>> allow httpd_fastcgi_script_t httpd_sys_script_exec_t:dir {
>> search_dir_perms };
>>
>> # Allow FastCGI applications to listen for FastCGI requests on their
>> # sockets and respond to them
>> allow httpd_fastcgi_script_t httpd_t:unix_stream_socket {
>> rw_stream_socket_perms };
>>
>> # FastCGI application doing something to the httpd error log
>> dontaudit httpd_fastcgi_script_t httpd_log_t:file ioctl;
>>
>> # Not sure what this is doing (happens when fastcgi scripts start)
>> dontaudit httpd_t devpts_t:chr_file ioctl;
>>
>> # mod_fcgid setting attr of its socket dir
>> allow httpd_t var_run_t:dir setattr;
>>
> Why not create a context for its socket dir so you don't need this for
> var_run?
>
The obvious type to use would really be httpd_var_run_t rather than
creating a new type (comparing with other users of /var/run). In fact I
think I tried that but it seemed worse than leaving it the default
var_run_t and adding the one allow rule. What would you suggest?
What errors do you see?
We already have these rules in policy
allow httpd_t httpd_var_run_t:file create_file_perms;
allow httpd_t httpd_var_run_t:sock_file create_file_perms;
allow httpd_t httpd_var_run_t:dir rw_dir_perms;
files_pid_filetrans(httpd_t,httpd_var_run_t, { file sock_file })
Which should be able to handle this if you relabel the /var/run/XYZ dir.
>> fc file:
>>
>> /srv/www/tips/cgi-bin/moin.fcgi --
>> gen_context(system_u:object_r:httpd_fastcgi_script_exec_t,s0)
>> /var/www/tips/cgi-bin/moin.fcgi --
>> gen_context(system_u:object_r:httpd_fastcgi_script_exec_t,s0)
>>
>> Paul.
>>
> I think it might be a good idea to add this (fastcgi that is) policy to
> base. Have you tried to submit it upstream?
>
Not yet; it probably needs more work to add further capabilities, as
I've only use one application with FastCGI myself, and I can see that
httpd_sys_script_t has far more capabilities that I've so far allowed to
httpd_fastcgi_script_t. Perhaps there should be a interface that goes
further than apache_content_template and adds capabilities needed by
most server-side scripts (e.g. the kernel_read_kernel_sysctls from
above), for use in developing custom types like httpd_fastcgi_script_t?
Paul.
you could create an
apache_fastcgi_content_template in an if to do what you want.
Almost all httpd_sys_ rules are defined in apache_content_template
3:45 p.m.
New subject: CGI Script permissions
On Thu, 2006-06-08 at 15:03 -0400, Daniel J Walsh wrote:
Paul Howarth wrote:
> On Fri, 2006-05-26 at 14:18 -0400, Daniel J Walsh wrote:
>
>> Paul Howarth wrote:
>>
>>> I made something similar for my moin wiki running under mod_fcgid:
>>>
>>> te file:
>>>
>>> policy_module(apache, 0.2.1)
>>>
>>> require {
>>> type devpts_t;
>>> type httpd_t;
>>> type httpd_log_t;
>>> type httpd_sys_script_exec_t;
>>> type var_run_t;
>>> };
>>>
>>> # ==========================================================
>>> # Create and use httpd_fastcgi_script_t for mod_fcgid apps
>>> # ==========================================================
>>>
>>> apache_content_template(fastcgi)
>>> kernel_read_kernel_sysctls(httpd_fastcgi_script_t)
>>>
>>> # Allow FastCGI applications to live alongside regular CGI apps
>>> allow httpd_fastcgi_script_t httpd_sys_script_exec_t:dir {
>>> search_dir_perms };
>>>
>>> # Allow FastCGI applications to listen for FastCGI requests on their
>>> # sockets and respond to them
>>> allow httpd_fastcgi_script_t httpd_t:unix_stream_socket {
>>> rw_stream_socket_perms };
>>>
>>> # FastCGI application doing something to the httpd error log
>>> dontaudit httpd_fastcgi_script_t httpd_log_t:file ioctl;
>>>
>>> # Not sure what this is doing (happens when fastcgi scripts start)
>>> dontaudit httpd_t devpts_t:chr_file ioctl;
>>>
>>> # mod_fcgid setting attr of its socket dir
>>> allow httpd_t var_run_t:dir setattr;
>>>
>> Why not create a context for its socket dir so you don't need this for
>> var_run?
>>
>
> The obvious type to use would really be httpd_var_run_t rather than
> creating a new type (comparing with other users of /var/run). In fact I
> think I tried that but it seemed worse than leaving it the default
> var_run_t and adding the one allow rule. What would you suggest?
>
>
What errors do you see?
We already have these rules in policy
allow httpd_t httpd_var_run_t:file create_file_perms;
allow httpd_t httpd_var_run_t:sock_file create_file_perms;
allow httpd_t httpd_var_run_t:dir rw_dir_perms;
files_pid_filetrans(httpd_t,httpd_var_run_t, { file sock_file })
Which should be able to handle this if you relabel the /var/run/XYZ dir.
Looks like it's just the same one now:
type=AVC msg=audit(1149799121.917:265395): avc: denied { setattr } for
pid=10825 comm="httpd" name="mod_fcgid" dev=dm-4 ino=458818
scontext=user_u:system_r:httpd_t:s0
tcontext=system_u:object_r:httpd_var_run_t:s0 tclass=dirtype=SYSCALL
msg=audit(1149799121.917:265395): arch=40000003 syscall=212 success=yes
exit=0 a0=87639d0 a1=30 a2=ffffffff a3=30 items=1 pid=10825 auid=500
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="httpd"
exe="/usr/sbin/httpd"
type=CWD msg=audit(1149799121.917:265395): cwd="/"
type=PATH msg=audit(1149799121.917:265395): item=0
name="/etc/httpd/run/mod_fcgid" flags=1 inode=458818 dev=fd:04
mode=040755 ouid=48 ogid=48 rdev=00:00
(/etc/httpd/run is a symlink to /var/run)
So I guess I just change the rule to be for httpd_var_run_t rather than
var_run_t (rw_dir_perms doesn't include setattr)?
>>> fc file:
>>>
>>> /srv/www/tips/cgi-bin/moin.fcgi --
>>> gen_context(system_u:object_r:httpd_fastcgi_script_exec_t,s0)
>>> /var/www/tips/cgi-bin/moin.fcgi --
>>> gen_context(system_u:object_r:httpd_fastcgi_script_exec_t,s0)
>>>
>>> Paul.
>>>
>> I think it might be a good idea to add this (fastcgi that is) policy to
>> base. Have you tried to submit it upstream?
>>
>
> Not yet; it probably needs more work to add further capabilities, as
> I've only use one application with FastCGI myself, and I can see that
> httpd_sys_script_t has far more capabilities that I've so far allowed to
> httpd_fastcgi_script_t. Perhaps there should be a interface that goes
> further than apache_content_template and adds capabilities needed by
> most server-side scripts (e.g. the kernel_read_kernel_sysctls from
> above), for use in developing custom types like httpd_fastcgi_script_t?
>
> Paul.
>
>
>
you could create an
apache_fastcgi_content_template in an if to do what you want.
Almost all httpd_sys_ rules are defined in apache_content_template
What I currently have is:
policy_module(fastcgi, 0.1.0)
require {
type devpts_t;
type httpd_t;
type httpd_config_t;
type httpd_log_t;
type httpd_sys_script_exec_t;
type httpd_sys_content_t;
type var_run_t;
};
# ==========================================================
# Create and use httpd_fastcgi_script_t for mod_fcgid apps
# ==========================================================
apache_content_template(fastcgi)
kernel_read_kernel_sysctls(httpd_fastcgi_script_t)
# Allow FastCGI applications to live alongside regular CGI apps
allow httpd_fastcgi_script_t httpd_sys_script_exec_t:dir
{ search_dir_perms };
allow httpd_fastcgi_script_t httpd_sys_content_t:dir
{ search_dir_perms };
# Allow FastCGI applications to read the routing table
allow httpd_fastcgi_script_t self:netlink_route_socket
{ r_netlink_socket_perms };
# Allow FastCGI applications to listen for FastCGI requests on their
# sockets and respond to them
allow httpd_fastcgi_script_t httpd_t:unix_stream_socket
{ rw_stream_socket_perms };
# FastCGI application doing something to the httpd error log
dontaudit httpd_fastcgi_script_t httpd_log_t:file ioctl;
# Not sure what this is doing (happens when fastcgi scripts start)
dontaudit httpd_t devpts_t:chr_file ioctl;
# mod_fcgid setting attr of its socket dir
allow httpd_t var_run_t:dir setattr;
# ======================================================
# Equivalent policy cribbed from httpd_sys_script_t
# ======================================================
dontaudit httpd_fastcgi_script_t httpd_config_t:dir search;
files_search_var_lib(httpd_fastcgi_script_t)
files_search_spool(httpd_fastcgi_script_t)
ifdef(`distro_redhat',`
allow httpd_fastcgi_script_t httpd_log_t:file { getattr
append };
')
ifdef(`targeted_policy',`
tunable_policy(`httpd_enable_homedirs',`
userdom_search_generic_user_home_dirs(httpd_fastcgi_script_t)
')
')
optional_policy(`
mysql_stream_connect(httpd_fastcgi_script_t)
mysql_rw_db_sockets(httpd_fastcgi_script_t)
')
Paul.
7:37 a.m.
New subject: CGI Script permissions
Paul Howarth wrote:
On Thu, 2006-06-08 at 15:03 -0400, Daniel J Walsh wrote:
> Paul Howarth wrote:
>> On Fri, 2006-05-26 at 14:18 -0400, Daniel J Walsh wrote:
>>
>>> Paul Howarth wrote:
>>>
>>>> I made something similar for my moin wiki running under mod_fcgid:
>>>>
>>>> te file:
>>>>
>>>> policy_module(apache, 0.2.1)
>>>>
>>>> require {
>>>> type devpts_t;
>>>> type httpd_t;
>>>> type httpd_log_t;
>>>> type httpd_sys_script_exec_t;
>>>> type var_run_t;
>>>> };
>>>>
>>>> # ==========================================================
>>>> # Create and use httpd_fastcgi_script_t for mod_fcgid apps
>>>> # ==========================================================
>>>>
>>>> apache_content_template(fastcgi)
>>>> kernel_read_kernel_sysctls(httpd_fastcgi_script_t)
>>>>
>>>> # Allow FastCGI applications to live alongside regular CGI apps
>>>> allow httpd_fastcgi_script_t httpd_sys_script_exec_t:dir {
>>>> search_dir_perms };
>>>>
>>>> # Allow FastCGI applications to listen for FastCGI requests on their
>>>> # sockets and respond to them
>>>> allow httpd_fastcgi_script_t httpd_t:unix_stream_socket {
>>>> rw_stream_socket_perms };
>>>>
>>>> # FastCGI application doing something to the httpd error log
>>>> dontaudit httpd_fastcgi_script_t httpd_log_t:file ioctl;
>>>>
>>>> # Not sure what this is doing (happens when fastcgi scripts start)
>>>> dontaudit httpd_t devpts_t:chr_file ioctl;
>>>>
>>>> # mod_fcgid setting attr of its socket dir
>>>> allow httpd_t var_run_t:dir setattr;
>>>>
>>> Why not create a context for its socket dir so you don't need this for
>>> var_run?
>>>
>> The obvious type to use would really be httpd_var_run_t rather than
>> creating a new type (comparing with other users of /var/run). In fact I
>> think I tried that but it seemed worse than leaving it the default
>> var_run_t and adding the one allow rule. What would you suggest?
>>
>>
> What errors do you see?
>
> We already have these rules in policy
>
> allow httpd_t httpd_var_run_t:file create_file_perms;
> allow httpd_t httpd_var_run_t:sock_file create_file_perms;
> allow httpd_t httpd_var_run_t:dir rw_dir_perms;
> files_pid_filetrans(httpd_t,httpd_var_run_t, { file sock_file })
>
> Which should be able to handle this if you relabel the /var/run/XYZ dir.
Looks like it's just the same one now:
type=AVC msg=audit(1149799121.917:265395): avc: denied { setattr } for
pid=10825 comm="httpd" name="mod_fcgid" dev=dm-4 ino=458818
scontext=user_u:system_r:httpd_t:s0
tcontext=system_u:object_r:httpd_var_run_t:s0 tclass=dirtype=SYSCALL
msg=audit(1149799121.917:265395): arch=40000003 syscall=212 success=yes
exit=0 a0=87639d0 a1=30 a2=ffffffff a3=30 items=1 pid=10825 auid=500
uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="httpd"
exe="/usr/sbin/httpd"
type=CWD msg=audit(1149799121.917:265395): cwd="/"
type=PATH msg=audit(1149799121.917:265395): item=0
name="/etc/httpd/run/mod_fcgid" flags=1 inode=458818 dev=fd:04
mode=040755 ouid=48 ogid=48 rdev=00:00
(/etc/httpd/run is a symlink to /var/run)
So I guess I just change the rule to be for httpd_var_run_t rather than
var_run_t (rw_dir_perms doesn't include setattr)?
I decided to use a completely new type instead of reusing an existing one.
New policy:
####### fastcgi.fc #######
/var/run/mod_fcgid(/.*)?
gen_context(system_u:object_r:httpd_fastcgi_sock_t,s0)
####### fastcgi.te #######
policy_module(fastcgi, 0.1.2)
type httpd_fastcgi_sock_t;
files_type(httpd_fastcgi_sock_t)
require {
type devpts_t;
type httpd_t;
type httpd_config_t;
type httpd_log_t;
type httpd_sys_script_exec_t;
type httpd_sys_content_t;
};
# ==========================================================
# Create and use httpd_fastcgi_script_t for mod_fcgid apps
# ==========================================================
apache_content_template(fastcgi)
kernel_read_kernel_sysctls(httpd_fastcgi_script_t)
# Allow FastCGI applications to live alongside regular CGI apps
allow httpd_fastcgi_script_t httpd_sys_script_exec_t:dir {
search_dir_perms };
allow httpd_fastcgi_script_t httpd_sys_content_t:dir { search_dir_perms };
# Allow FastCGI applications to read the routing table
allow httpd_fastcgi_script_t self:netlink_route_socket {
r_netlink_socket_perms };
# Allow httpd to create and use sockets for communicating with mod_fcgid
allow httpd_t httpd_fastcgi_sock_t:dir { rw_dir_perms setattr };
allow httpd_t httpd_fastcgi_sock_t:sock_file { create_file_perms };
# Allow FastCGI applications to listen for FastCGI requests on their
# sockets and respond to them
allow httpd_fastcgi_script_t httpd_t:unix_stream_socket {
rw_stream_socket_perms };
# FastCGI application doing something to the httpd error log
dontaudit httpd_fastcgi_script_t httpd_log_t:file ioctl;
# Not sure what this is doing (happens when fastcgi scripts start)
dontaudit httpd_t devpts_t:chr_file ioctl;
# ======================================================
# Equivalent policy cribbed from httpd_sys_script_t
# ======================================================
dontaudit httpd_fastcgi_script_t httpd_config_t:dir search;
files_search_var_lib(httpd_fastcgi_script_t)
files_search_spool(httpd_fastcgi_script_t)
ifdef(`distro_redhat',`
allow httpd_fastcgi_script_t httpd_log_t:file { getattr append };
')
ifdef(`targeted_policy',`
tunable_policy(`httpd_enable_homedirs',`
userdom_search_generic_user_home_dirs(httpd_fastcgi_script_t)
')
')
optional_policy(`
mysql_stream_connect(httpd_fastcgi_script_t)
mysql_rw_db_sockets(httpd_fastcgi_script_t)
')
Paul.
9:34 a.m.
New subject: CGI Script permissions
Paul Howarth wrote:
Paul Howarth wrote:
> On Thu, 2006-06-08 at 15:03 -0400, Daniel J Walsh wrote:
>> Paul Howarth wrote:
>>> On Fri, 2006-05-26 at 14:18 -0400, Daniel J Walsh wrote:
>>>> Paul Howarth wrote:
>>>>
>>>>> I made something similar for my moin wiki running under mod_fcgid:
>>>>>
>>>>> te file:
>>>>>
>>>>> policy_module(apache, 0.2.1)
>>>>>
>>>>> require {
>>>>> type devpts_t;
>>>>> type httpd_t;
>>>>> type httpd_log_t;
>>>>> type httpd_sys_script_exec_t;
>>>>> type var_run_t;
>>>>> };
>>>>>
>>>>> # ==========================================================
>>>>> # Create and use httpd_fastcgi_script_t for mod_fcgid apps
>>>>> # ==========================================================
>>>>>
>>>>> apache_content_template(fastcgi)
>>>>> kernel_read_kernel_sysctls(httpd_fastcgi_script_t)
>>>>>
>>>>> # Allow FastCGI applications to live alongside regular CGI apps
>>>>> allow httpd_fastcgi_script_t httpd_sys_script_exec_t:dir {
>>>>> search_dir_perms };
>>>>>
>>>>> # Allow FastCGI applications to listen for FastCGI requests on their
>>>>> # sockets and respond to them
>>>>> allow httpd_fastcgi_script_t httpd_t:unix_stream_socket {
>>>>> rw_stream_socket_perms };
>>>>>
>>>>> # FastCGI application doing something to the httpd error log
>>>>> dontaudit httpd_fastcgi_script_t httpd_log_t:file ioctl;
>>>>>
>>>>> # Not sure what this is doing (happens when fastcgi scripts start)
>>>>> dontaudit httpd_t devpts_t:chr_file ioctl;
>>>>>
>>>>> # mod_fcgid setting attr of its socket dir
>>>>> allow httpd_t var_run_t:dir setattr;
>>>>>
>>>> Why not create a context for its socket dir so you don't need this
>>>> for var_run?
>>>>
>>> The obvious type to use would really be httpd_var_run_t rather than
>>> creating a new type (comparing with other users of /var/run). In fact I
>>> think I tried that but it seemed worse than leaving it the default
>>> var_run_t and adding the one allow rule. What would you suggest?
>>>
>>>
>> What errors do you see?
>>
>> We already have these rules in policy
>>
>> allow httpd_t httpd_var_run_t:file create_file_perms;
>> allow httpd_t httpd_var_run_t:sock_file create_file_perms;
>> allow httpd_t httpd_var_run_t:dir rw_dir_perms;
>> files_pid_filetrans(httpd_t,httpd_var_run_t, { file sock_file })
>>
>> Which should be able to handle this if you relabel the /var/run/XYZ dir.
>
> Looks like it's just the same one now:
>
> type=AVC msg=audit(1149799121.917:265395): avc: denied { setattr } for
> pid=10825 comm="httpd" name="mod_fcgid" dev=dm-4 ino=458818
> scontext=user_u:system_r:httpd_t:s0
> tcontext=system_u:object_r:httpd_var_run_t:s0 tclass=dirtype=SYSCALL
> msg=audit(1149799121.917:265395): arch=40000003 syscall=212 success=yes
> exit=0 a0=87639d0 a1=30 a2=ffffffff a3=30 items=1 pid=10825 auid=500
> uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="httpd"
> exe="/usr/sbin/httpd"
> type=CWD msg=audit(1149799121.917:265395): cwd="/"
> type=PATH msg=audit(1149799121.917:265395): item=0
> name="/etc/httpd/run/mod_fcgid" flags=1 inode=458818 dev=fd:04
> mode=040755 ouid=48 ogid=48 rdev=00:00
>
> (/etc/httpd/run is a symlink to /var/run)
>
> So I guess I just change the rule to be for httpd_var_run_t rather than
> var_run_t (rw_dir_perms doesn't include setattr)?
I decided to use a completely new type instead of reusing an existing one.
New policy:
####### fastcgi.fc #######
/var/run/mod_fcgid(/.*)?
gen_context(system_u:object_r:httpd_fastcgi_sock_t,s0)
####### fastcgi.te #######
policy_module(fastcgi, 0.1.2)
type httpd_fastcgi_sock_t;
files_type(httpd_fastcgi_sock_t)
require {
type devpts_t;
type httpd_t;
type httpd_config_t;
type httpd_log_t;
type httpd_sys_script_exec_t;
type httpd_sys_content_t;
};
# ==========================================================
# Create and use httpd_fastcgi_script_t for mod_fcgid apps
# ==========================================================
apache_content_template(fastcgi)
kernel_read_kernel_sysctls(httpd_fastcgi_script_t)
# Allow FastCGI applications to live alongside regular CGI apps
allow httpd_fastcgi_script_t httpd_sys_script_exec_t:dir {
search_dir_perms };
allow httpd_fastcgi_script_t httpd_sys_content_t:dir { search_dir_perms };
# Allow FastCGI applications to read the routing table
allow httpd_fastcgi_script_t self:netlink_route_socket {
r_netlink_socket_perms };
# Allow httpd to create and use sockets for communicating with mod_fcgid
allow httpd_t httpd_fastcgi_sock_t:dir { rw_dir_perms setattr };
allow httpd_t httpd_fastcgi_sock_t:sock_file { create_file_perms };
# Allow FastCGI applications to listen for FastCGI requests on their
# sockets and respond to them
allow httpd_fastcgi_script_t httpd_t:unix_stream_socket {
rw_stream_socket_perms };
# FastCGI application doing something to the httpd error log
dontaudit httpd_fastcgi_script_t httpd_log_t:file ioctl;
# Not sure what this is doing (happens when fastcgi scripts start)
dontaudit httpd_t devpts_t:chr_file ioctl;
# ======================================================
# Equivalent policy cribbed from httpd_sys_script_t
# ======================================================
dontaudit httpd_fastcgi_script_t httpd_config_t:dir search;
files_search_var_lib(httpd_fastcgi_script_t)
files_search_spool(httpd_fastcgi_script_t)
ifdef(`distro_redhat',`
allow httpd_fastcgi_script_t httpd_log_t:file { getattr append };
')
ifdef(`targeted_policy',`
tunable_policy(`httpd_enable_homedirs',`
userdom_search_generic_user_home_dirs(httpd_fastcgi_script_t)
')
')
optional_policy(`
mysql_stream_connect(httpd_fastcgi_script_t)
mysql_rw_db_sockets(httpd_fastcgi_script_t)
')
I have now submitted my mod_fcgid package, which includes this policy
module, for review for Fedora Extras:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195666
Paul.
6517
days inactive
6538
days old
selinux@lists.fedoraproject.org
8 comments
3 participants
participants (3)
-
Daniel J Walsh -
Jochen Wiedmann -
Paul Howarth