Sample Passenger/Rails policy for review
by Moray Henderson (ICT)
Hi all,
I've been looking at getting a Ruby on Rails app working through
Passenger under CentOS 5.5. I felt it should run in its own security
context, so I came up with the following sample module. Please comment.
Summary
-------
The policy creates a new set of apache content types using
apache_content_template. The Passenger ApplicationPoolServerExecutable
is given type httpd_myapp_script_exec_t, so the app will execute in
httpd_myapp_script_t. The remaining Passenger files, and the Rails app
itself, are httpd_myapp_content_t. PassengerTempDir is set to
/var/run/passenger, and given httpd_myapp_script_rw_t to allow the
sockets and stuff to be created.
Source
------
#### myapp.te ####
policy_module(myapp,1.0)
# Create a set of apache content types for myapp
apache_content_template(myapp);
# Give running app access to system things it will ask for
kernel_read_kernel_sysctls(httpd_myapp_script_t);
miscfiles_read_certs(httpd_myapp_script_t);
term_use_all_user_ptys(httpd_myapp_script_t);
# Allow apache to create and communicate with Passenger
allow httpd_t self:capability { fowner fsetid };
allow httpd_t httpd_myapp_script_t:unix_stream_socket rw_socket_perms;
allow httpd_t httpd_myapp_script_t:process { siginh rlimitinh noatsecure
};
allow httpd_t httpd_myapp_script_rw_t:fifo_file manage_file_perms;
allow httpd_t httpd_myapp_script_rw_t:sock_file { setattr unlink };
# Access that Passenger will need
allow httpd_myapp_script_t self:capability { chown dac_override
dac_read_search fowner fsetid setgid setuid };
allow httpd_myapp_script_t httpd_t:unix_stream_socket { read write };
#### myapp.fc ####
/usr/lib/ruby/gems/1.9.1/gems/passenger-2.2.15/lib/phusion_passenger/App
licationPoolServerExecutable --
gen_context(system_u:object_r:httpd_myapp_script_exec_t, s0)
/usr/lib/ruby/gems/1.9.1/gems/passenger-2.2.15(/.*)?
gen_context(system_u:object_r:httpd_myapp_content_t, s0)
/usr/local/lib/myapp(/.*)?
gen_context(system_u:object_r:httpd_myapp_content_t, s0)
/var/run/passenger(/.*)?
gen_context(system_u:object_r:httpd_myapp_script_rw_t, s0)
Moray.
"To err is human. To purr, feline"
13 years, 8 months
F12/3: SELinux is preventing /usr/bin/perl from binding to port XXXXX
by Dan Thurman
Every once in awhile I get these spurious message, high CPU usage,
repeated denials > 512 times and then it quits. I do not have ypbind,
nis, nor nfs installed. I even tried /.autorelabel and same issue comes
up. I do have spamassassin installed though.
So how do I resolve this?
===================================================
Summary:
SELinux is preventing /usr/bin/perl from binding to port 32726.
Detailed Description:
SELinux has denied the spamassassin from binding to a network port 32726
which
does not have an SELinux type associated with it. If spamassassin should be
allowed to listen on 32726, use the semanage command to assign 32726 to
a port
type that spamc_t can bind to ().
If spamassassin is not supposed to bind to 32726, this could signal an
intrusion
attempt.
Allowing Access:
If you want to allow spamassassin to bind to port 32726, you can execute
# semanage port -a -t PORT_TYPE -p udp 32726
where PORT_TYPE is one of the following: .
If this system is running as an NIS Client, turning on the allow_ypbind
boolean
may fix the problem. setsebool -P allow_ypbind=1.
Additional Information:
Source Context system_u:system_r:spamc_t:s0
Target Context system_u:object_r:port_t:s0
Target Objects None [ udp_socket ]
Source spamassassin
Source Path /usr/bin/perl
Port 32726
Host (removed)
Source RPM Packages perl-5.10.1-116.fc13
Target RPM Packages
Policy RPM selinux-policy-3.7.19-44.fc13
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Plugin Name bind_ports
Host Name (removed)
Platform Linux (removed) 2.6.33.6-147.2.4.fc13.i686 #1
SMP Fri Jul 23 17:27:40 UTC 2010 i686 i686
Alert Count 512
First Seen Tue 17 Aug 2010 02:00:10 PM PDT
Last Seen Tue 17 Aug 2010 04:05:25 PM PDT
Local ID 280d928d-03f6-42c5-99f8-eb23cb24a236
Line Numbers
Raw Audit Messages
node=(removed) type=AVC msg=audit(1282086325.907:81309): avc: denied {
name_bind } for pid=23536 comm="spamassassin" src=32726
scontext=system_u:system_r:spamc_t:s0
tcontext=system_u:object_r:port_t:s0 tclass=udp_socket
node=(removed) type=SYSCALL msg=audit(1282086325.907:81309):
arch=40000003 syscall=102 success=no exit=-13 a0=2 a1=bfae7100
a2=654b4d4 a3=9fd1008 items=0 ppid=23535 pid=23536 auid=4294967295
uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500
tty=(none) ses=4294967295 comm="spamassassin" exe="/usr/bin/perl"
subj=system_u:system_r:spamc_t:s0 key=(null)
13 years, 8 months
Re: Sample Passenger/Rails policy for review
by Jason Axelson
Hi Moray,
On Tue, Aug 17, 2010 at 5:34 AM, Moray Henderson
<Moray.Henderson(a)ict-software.org> wrote:
> Are any of the macros in /usr/share/selinux/devel/include/support/
> documented anywhere? I couldn't find them in the Tresys Refpolicy API
> documentation or the selinuxproject.org wiki.
Have you tried doing a "make html" in the refpolicy source? That will
generate a nice html interface to the macros, although there are many
so it can still be hard to tell which one would be best to use. Not
sure if you'll have it with your distribution but if you download from
tresys directly [1] you will be fine.
1. http://oss.tresys.com/projects/refpolicy
Jason
13 years, 8 months
Re: avc { module_request, relabelfrom }: openvpn->tun
by Mr Dash Four
>>>>> kernel_request_load_module(openvpn_t)
>>>>>
>>> create module that allows openvpn_t to request the kernel to load a module:
>>>
>>> mkdir ~/myopenvpn; cd ~/myopenvpn;
>>> echo "policy_module(myopenvpn, 1.0.0)" > myopenvpn.te;
>>> echo "gen_require(\`" >> myopenvpn.te;
>>> echo "type openvpn_t;" >> myopenvpn.te;
>>> echo "')" >> myopenvpn.te;
>>> echo "kernel_request_load_module(openvpn_t)" >> myopenvpn.te;
>>> make -f /usr/share/selinux/devel/Makefile myopenvpn.pp
>>> sudo semodule -i myopenvpn.pp
>>>
I see that this change has been adopted with the -47 version of the
policy (FC13) - that was pretty quick!
There was a suggestion for change to tor.te a while ago as well (see
tor: dac_override, dac_read_search, name_bind and net_bind_service
thread) - the new version of tor (2.x) provides dns resolution as part
of the service it runs, so it needs to bind to udp/53 and the statement:
corenet_udp_bind_dns_port(tor_t)
does the trick when it is included in tor.te. Currently I do this with
patching, but it would be nice to have it as part of the policy in a
similar way it was done with openvpn.
13 years, 8 months
Re: [refpolicy] [PATCH] revise roles/dbadm.te (Re: dbadm.pp is not available in selinux-policy package)
by KaiGai Kohei
(2010/08/18 3:00), Chris PeBenito wrote:
> On 08/16/10 19:37, KaiGai Kohei wrote:
>> (2010/08/17 4:42), Christopher J. PeBenito wrote:
>>> On 08/16/10 05:11, KaiGai Kohei wrote:
>>>> Sorry for this long silent on the topic.
>>>>
>>>> IIRC, we have already agreed most part of the patch, haven't we?
>>>>
>>>> - The dbadm_t domain shall be launched via sudo, not a login shell,
>>>> so, userdom_base_user_template() is used to grant basic privileges
>>>> to dbadm_t instead of userdom_unpriv_user_template().
>>>> - It allows too much privileges to dbadm_t, if we allows him to launch
>>>> setfiles, so we removed seutil_domtrans_setfiles().
>>>>
>>>> Did we have any more issues?
>>>>
>>>> The attached patch is same as the last version except for it was
>>>> rebased
>>>> to the latest reference policy.
>>>
>>> I only have two issues:
>>>
>>> 1. Why should dbadm be allowed to set enforce mode?
>>
>> It uses selinux_get_enforce_mode(), not selinux_set_enforce_mode().
>> We just allow dbadm_t to see the current working mode.
>
> My mistake, I misread it. You're right, its fine.
>
>>> 2. Why does dbadm need to manage generic locks?
>>
>> It was originally copied from webadb.te, but PostgreSQL also makes
>> its lockfile on the /var/lock/subsys/postgresql. If server process
>> unexpectedly crashed, dbadm_t need to remove it by hand, doesn't it?
>
> Based on what I see in the policy, my guess is this file is created by
> the init script, right? If not, then it sounds like PostgreSQL needs a
> lock type.
>
Yes, this file is created by the init script.
In addition, postgresql_lock_t is defined, but type_transition rule is
defined on a pair of postgresql_t and var_lock_t, so the lockfile shall
be labeled as var_lock_t.
[root@saba ~]# ls -Z /var/lock/subsys/postgresql
-rw-r--r--. root root dbadm_u:object_r:var_lock_t:s0 /var/lock/subsys/postgresql
Maybe, init script should relabel it to postgresql_lock_t, ideally?
> I'd rather it just have delete permissions, rather than full manage
> permissions. Something like files_delete_all_locks(), but for var_lock_t
> instead.
>
I tried to define files_delete_generic_locks(), instead of the manage.
Thanks,
--
KaiGai Kohei <kaigai(a)ak.jp.nec.com>
13 years, 8 months
SELinux integration in LDAP
by Matthias Imsand
Hello,
I’m referring to an older post (may 2008)
http://lists.fedoraproject.org/pipermail/selinux/2008-May/009449.html
The question is, if it’s possible to administer SELinux users and RBAC
stuff (like roles) in LDAP?
Are there some developments on this?
What about FreeIPA, do they have some sample code / libraries that I could
integrate in our company?
In our company everything relies on LDAP. So I must have a solution for
integrating SELinux in LDAP.
Thanks in advance
imsand
13 years, 8 months
Re: [refpolicy] [PATCH] revise roles/dbadm.te (Re: dbadm.pp is not available in selinux-policy package)
by KaiGai Kohei
(2010/08/17 4:42), Christopher J. PeBenito wrote:
> On 08/16/10 05:11, KaiGai Kohei wrote:
>> Sorry for this long silent on the topic.
>>
>> IIRC, we have already agreed most part of the patch, haven't we?
>>
>> - The dbadm_t domain shall be launched via sudo, not a login shell,
>> so, userdom_base_user_template() is used to grant basic privileges
>> to dbadm_t instead of userdom_unpriv_user_template().
>> - It allows too much privileges to dbadm_t, if we allows him to launch
>> setfiles, so we removed seutil_domtrans_setfiles().
>>
>> Did we have any more issues?
>>
>> The attached patch is same as the last version except for it was rebased
>> to the latest reference policy.
>
> I only have two issues:
>
> 1. Why should dbadm be allowed to set enforce mode?
It uses selinux_get_enforce_mode(), not selinux_set_enforce_mode().
We just allow dbadm_t to see the current working mode.
> 2. Why does dbadm need to manage generic locks?
It was originally copied from webadb.te, but PostgreSQL also makes
its lockfile on the /var/lock/subsys/postgresql. If server process
unexpectedly crashed, dbadm_t need to remove it by hand, doesn't it?
Thanks,
> After those are resolved, it can be merged.
>
>> (2010/04/15 15:02), KaiGai Kohei wrote:
>>> (2010/04/14 0:57), Christopher J. PeBenito wrote:
>>>> On Tue, 2010-04-13 at 11:15 -0400, Daniel J Walsh wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> On 04/13/2010 09:17 AM, Christopher J. PeBenito wrote:
>>>>>> On Tue, 2010-04-13 at 09:28 +0900, KaiGai Kohei wrote:
>>>>>>> (2010/04/12 23:09), Christopher J. PeBenito wrote:
>>>>>>>> On Fri, 2010-04-09 at 14:29 +0900, KaiGai Kohei wrote:
>>>>>>>>> (2010/04/08 21:15), Daniel J Walsh wrote:
>>>>>>>>>> As Dominick stated. I prefer to think in terms of two
>>>>>>>>>> different roles.
>>>>>>>>>> Login Roles, and Roles to execute in when you have privileges
>>>>>>>>>> (IE Root).
>>>>>>>>>>
>>>>>>>>>> Login Roles/Types
>>>>>>>>>> staff_t, user_t, unconfined_t, xguest_t, guest_t
>>>>>>>>>>
>>>>>>>>>> Three interfaces can be used to create confined login users.
>>>>>>>>>>
>>>>>>>>>> userdom_restricted_user_template(guest)
>>>>>>>>>> userdom_restricted_xwindows_user_template(xguest)
>>>>>>>>>> userdom_unpriv_user_template(staff)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Admin Roles/Types
>>>>>>>>>> logadm_t, webadm_t, secadm_t, auditadm_t
>>>>>>>>>>
>>>>>>>>>> The following interface can be used to create an Admin ROle
>>>>>>>>>> userdom_base_user_template(logadm)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> sysadm_t is sort of a hybrid, most people use it as an Admin
>>>>>>>>>> Role.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I imagine that you login as a confined user and then use
>>>>>>>>>> sudo/newrole to
>>>>>>>>>> switch roles to one of the admin roles.
>>>>>>>>>
>>>>>>>>> The attached patch revises roles/dbadm.te (to be applied on the
>>>>>>>>> upstream
>>>>>>>>> reference policy). It uses userdom_base_user_template() instead
>>>>>>>>> of the
>>>>>>>>> userdom_unpriv_user_template(), and should be launched via
>>>>>>>>> sudo/newrole.
>>>>>>>>> In the default, it intends the dbadm_r role to be launched by
>>>>>>>>> staff_r role.
>>>>>>>>
>>>>>>>> Why does dbadm need to run setfiles?
>>>>>>>
>>>>>>> The database files (typically, /var/lib/(se)?pgsql/*) have to be
>>>>>>> labeled
>>>>>>> correctly, so I thought dbadm needs to run setfiles.
>>>>>>> However, as long as they initialize database files using init
>>>>>>> script,
>>>>>>> initrc_t domain performs this initial labeling, so it might not
>>>>>>> be necessary.
>>>>>>>
>>>>>>> On the other hand, PostgreSQL support a feature to use multiple
>>>>>>> disks
>>>>>>> within a single database instance for performance utilization.
>>>>>>> (Called TABLESPACE; I don't know whether MySQL has such a feature.)
>>>>>>>
>>>>>>> http://archives.postgresql.org/pgsql-general/2006-08/msg00142.php
>>>>>>>
>>>>>>> It requires administrators to assign proper security context on
>>>>>>> the secondary
>>>>>>> directory, or to mount the secondary disk with context='...' option.
>>>>>>>
>>>>>>> Is there any good idea?
>>>>>>>
>>>>>>> Or, it should not be a task for dbadm?
>>>>>>
>>>>>> Ok, the transition for setfiles is fine.
>>>>>>
>>>>>
>>>>> I would be carefull with this. Since setfiles can take a parameter
>>>>> of a
>>>>> file context file. I think it would be better to only give
>>>>> relabefrom/relabelto privs for all labels dbadm_t can manage. Then
>>>>> figure out what access is required to mount.
>>>>
>>>> Good point. We should probably reconsider the setfiles usage from
>>>> webadm too.
>>>
>>> The attached patch is a revised one.
>>> - seutil_domtrans_setfiles() was removed
>>> - staff_role_change_to() was removed, and I put dbadm_role_change()
>>> on the staff.te
>>> - Fix an obvious typo.
>>>
>>> It is not clear for me whether the idea to allow relabelfrom/relabelto
>>> for all the files dbadm_t can manage, because it is eventually necessary
>>> someone to relabel (or assign initial labels) files from unlabeled one
>>> to managed labels when we mount a new disk.
>>>
>>> If so, should it be a task of sysadm_t to mount new disk and assign
>>> security context correctly, instead of webadm_t/dbadm_t?
>>>
>>> Thanks,
>
--
KaiGai Kohei <kaigai(a)ak.jp.nec.com>
13 years, 8 months
Re: avc { module_request, relabelfrom }: openvpn->tun
by Mr Dash Four
The proposed modifications were tested and work without a hitch, so I am
making the changes permanent as part of my custom policy. Many thanks
Dominick for your input.
It is interesting though that when openvpn is restarted (which forces
the 'closure' of the tun device, which is then opened again by openvpn)
I do not get the 'relablefrom' avcs, but if I do open the tun device
'manually' (using 'openvpn --mktun') I do get these.
This modification also helped me find a bug in the openvpn config file I
was using (I have chrooted openvpn, but forgot to reset the SELinux
permissions on the 'local' copy of ip, so that caused problems as well -
easily fixed though), so that was an added bonus for me.
13 years, 8 months
Selinux + ruby + httpd
by Erinn Looney-Triggs
In trying to develop some SELinux exceptions (via audit2allow) for a
ruby application I came up with the following:
module myruby 1.0;
require {
type httpd_tmp_t;
type lib_t;
type httpd_t;
type tmp_t;
class sock_file { write create unlink getattr setattr };
class capability { fowner fsetid };
class file { read getattr execute_no_trans };
class fifo_file { create unlink getattr setattr };
}
#============= httpd_t ==============
allow httpd_t httpd_tmp_t:fifo_file { create unlink getattr setattr };
allow httpd_t httpd_tmp_t:sock_file { write create unlink getattr setattr };
allow httpd_t lib_t:file execute_no_trans; #This one is due to
mod_passenger being labelled lib_t
allow httpd_t self:capability { fowner fsetid };
allow httpd_t tmp_t:file { read getattr };
Now the first question I have, is there anything egregiously bad in
there? Aside from lib_t execute due to auto label labelling
mod_passenger as lib_t.
My second question is, I have this policy working on one machine, moved
it to another machine and everything worked, this application was then
deployed on a third machine and I figured, I would just insert the
module again. Well installing the module worked fine but apache is
trying to use a different type on this machine, from audit2allow:
#============= httpd_sys_script_t ==============
allow httpd_sys_script_t devpts_t:chr_file { read write };
allow httpd_sys_script_t httpd_tmp_t:fifo_file setattr;
allow httpd_sys_script_t self:capability { setuid setgid };
Why all the sudden is this machine using httpd_sys_script_t instead of
httpd_t which my other systems use? All the boxes are RHEL 5.5 x64 fully
patched running selinux-policy-2.4.6-279.el5. Now it is possible that
the myruby.pp module mentioned above is working just fine, but why then
would this one system need these extra privileges? Exact same codebase
for the ruby application across the systems. Any insight would be
appreciated.
Thanks,
-Erinn
13 years, 8 months
Re: [refpolicy] [PATCH] revise roles/dbadm.te (Re: dbadm.pp is not available in selinux-policy package)
by KaiGai Kohei
(2010/04/14 0:57), Christopher J. PeBenito wrote:
> On Tue, 2010-04-13 at 11:15 -0400, Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 04/13/2010 09:17 AM, Christopher J. PeBenito wrote:
>>> On Tue, 2010-04-13 at 09:28 +0900, KaiGai Kohei wrote:
>>>> (2010/04/12 23:09), Christopher J. PeBenito wrote:
>>>>> On Fri, 2010-04-09 at 14:29 +0900, KaiGai Kohei wrote:
>>>>>> (2010/04/08 21:15), Daniel J Walsh wrote:
>>>>>>> As Dominick stated. I prefer to think in terms of two different roles.
>>>>>>> Login Roles, and Roles to execute in when you have privileges (IE Root).
>>>>>>>
>>>>>>> Login Roles/Types
>>>>>>> staff_t, user_t, unconfined_t, xguest_t, guest_t
>>>>>>>
>>>>>>> Three interfaces can be used to create confined login users.
>>>>>>>
>>>>>>> userdom_restricted_user_template(guest)
>>>>>>> userdom_restricted_xwindows_user_template(xguest)
>>>>>>> userdom_unpriv_user_template(staff)
>>>>>>>
>>>>>>>
>>>>>>> Admin Roles/Types
>>>>>>> logadm_t, webadm_t, secadm_t, auditadm_t
>>>>>>>
>>>>>>> The following interface can be used to create an Admin ROle
>>>>>>> userdom_base_user_template(logadm)
>>>>>>>
>>>>>>>
>>>>>>> sysadm_t is sort of a hybrid, most people use it as an Admin Role.
>>>>>>>
>>>>>>>
>>>>>>> I imagine that you login as a confined user and then use sudo/newrole to
>>>>>>> switch roles to one of the admin roles.
>>>>>>
>>>>>> The attached patch revises roles/dbadm.te (to be applied on the upstream
>>>>>> reference policy). It uses userdom_base_user_template() instead of the
>>>>>> userdom_unpriv_user_template(), and should be launched via sudo/newrole.
>>>>>> In the default, it intends the dbadm_r role to be launched by staff_r role.
>>>>>
>>>>> Why does dbadm need to run setfiles?
>>>>
>>>> The database files (typically, /var/lib/(se)?pgsql/*) have to be labeled
>>>> correctly, so I thought dbadm needs to run setfiles.
>>>> However, as long as they initialize database files using init script,
>>>> initrc_t domain performs this initial labeling, so it might not be necessary.
>>>>
>>>> On the other hand, PostgreSQL support a feature to use multiple disks
>>>> within a single database instance for performance utilization.
>>>> (Called TABLESPACE; I don't know whether MySQL has such a feature.)
>>>>
>>>> http://archives.postgresql.org/pgsql-general/2006-08/msg00142.php
>>>>
>>>> It requires administrators to assign proper security context on the secondary
>>>> directory, or to mount the secondary disk with context='...' option.
>>>>
>>>> Is there any good idea?
>>>>
>>>> Or, it should not be a task for dbadm?
>>>
>>> Ok, the transition for setfiles is fine.
>>>
>>
>> I would be carefull with this. Since setfiles can take a parameter of a
>> file context file. I think it would be better to only give
>> relabefrom/relabelto privs for all labels dbadm_t can manage. Then
>> figure out what access is required to mount.
>
> Good point. We should probably reconsider the setfiles usage from
> webadm too.
The attached patch is a revised one.
- seutil_domtrans_setfiles() was removed
- staff_role_change_to() was removed, and I put dbadm_role_change()
on the staff.te
- Fix an obvious typo.
It is not clear for me whether the idea to allow relabelfrom/relabelto
for all the files dbadm_t can manage, because it is eventually necessary
someone to relabel (or assign initial labels) files from unlabeled one
to managed labels when we mount a new disk.
If so, should it be a task of sysadm_t to mount new disk and assign
security context correctly, instead of webadm_t/dbadm_t?
Thanks,
--
KaiGai Kohei <kaigai(a)ak.jp.nec.com>
13 years, 8 months
