>>> Hi,
>>>
>>> I've been working on a SElinux policy - it's ready for testing. Given the lack of testing outside of my local environments, I wouldn't recommend running this in a production environment yet - there will almost certainly be edge cases I haven't caught.
>>>
>>> There's support for all three major database engines and it assumes you're running under Passenger.
>>>
>>> Here is how to test it out:
>>>
>>> 1. Ensure selinux is enforcing (run getenforce if you're unsure)
>>> 2. wget http://skottler.fedorapeople.org/foreman/selinux/foreman.pp
>>> 3. semodule -i foreman.pp
>> /me dusts off his SELinux skills
> Thanks for testing!
>
>> So looking first at the file context regexes it's added:
>>
>> Should config files be labelled as logs? Maybe etc_t or a dedicated type?
>>
>> /etc/foreman(/.*)? all files
>> system_u:object_r:httpd_foreman_script_log_t:s0
> I don't think the configuration should be labelled as a log. etc_t seems
> fine, but it might make sense to create foreman_config_t. Completely
> open to ideas on that front.
I agree with foreman_config_t.
>> What paths should this be matching?
>>
>> foreman regular file
>> system_u:object_r:httpd_foreman_script_exec_t:s0
Any thoughts on that - what's httpd_foreman_script_exec_t used for?
>> I'm getting an AVC from the "Passenger ApplicationSpawner:
>> /usr/share/foreman" process trying to write to my sqlite database:
>>
>> type=AVC msg=audit(1362590838.549:39197): avc: denied { write } for
>> pid=2093 comm="ruby" name="production.sqlite3" dev=dm-0 ino=521782
>> scontext=system_u:system_r:httpd_t:s0
>> tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file
> I can't reproduce this on RHEL 6.4 - is there anything special about
> your environment? Are you using /usr/share/foreman for your installation?
There are special things, but hopefully this isn't one of them 
It's a package install, so /usr/share/foreman/db is a symlink to
/var/lib/foreman/db. I don't see any rules permitting httpd_t write
access to var_lib_t files:
sesearch --allow -s httpd_t -t var_lib_t
Found 7 semantic av rules:
allow httpd_t var_lib_t : file { ioctl read getattr lock open } ;
allow httpd_t var_lib_t : dir { ioctl read write getattr lock
add_name remove_name search open } ;
^^ only directories here
allow httpd_t var_lib_t : lnk_file { read getattr } ;
allow httpd_t file_type : filesystem getattr ;
allow daemon var_lib_t : dir { getattr search open } ;
allow httpd_t var_lib_t : dir { getattr search open } ;
allow httpd_t var_lib_t : dir { getattr search open } ;
>> I guess it should be labelled something other than var_lib_t, but what?
> var_lib_t seemed to be the closest thing to reasonable, but in
> retrospect that probably isn't true
>
> Let me think on this and dig around to find how others are doing it.
Yeah, I think a new type would help for labelling the database and then
httpd_t can be given access to it (rather than all of var_lib_t).
>> That looks to be it for the Foreman process on my system (Foreman 1.1,
>> RHEL 6.4, x86_64, sqlite). I've done a simple build but haven't used
>> compute resources, which probably requires some work too.
> We spoke about this on IRC, but I tested with ovirt and openstack, but
> I'd love to get libvirt tested as well.
Here's a denial using libvirt over SSH:
type=AVC msg=audit(1362644172.651:53): avc: denied { name_connect }
for pid=2204 comm="ssh" dest=22 scontext=system_u:system_r:httpd_t:s0
tcontext=system_u:object_r:ssh_port_t:s0 tclass=tcp_socket
I didn't see anything when launching an EC2 instance, was expecting
another ssh_port_t as above.
Cheers,
···
On 07/03/13 00:38, Sam Kottler wrote:
> On 03/06/2013 12:51 PM, Dominic Cleal wrote:
>> On 06/03/13 03:07, Sam Kottler wrote:
–
Dominic Cleal
Red Hat Engineering
