• 1
Is any plan making boolean per-domain? Just current implementation is similary strange. We have a globaly defined variable for specified application, so can't make a different rules for different instances of one app... this not a stopper and WA exist, but ... that's strange :)

Not sure what you mean. You can define a boolean any way you want in policy.

Many thanks, Dan, for thorough explanation. I followed your instructions and verified in my CentOS 6.4 release, although the output in my box differs from yours a little, I have amlost clear understanding, except a few minor points:

1) say in this rule,

allow httpd_t postgresql_port_t : tcp_socket { recv_msg send_msg name_connect } ;

httpd_selinux(8) says httpd_t type is entered via the httpd_exec_t file type whose label rules can be found in /etc/selinux/targeted/modules/active/file_contexts. And by either seinfo or semanage the postgresql_port_t port type can be verified as tcp/5432.

I read tcp_sockt as resource class and those in curly brackets are permissions, but there is still a minor gap between them and my old understanding of Linux system APIs. How can I resolve the gap?

2) I read the 'allow source_type target_type: resoure_class { permissions }' as kind of policy language syntax. And I recall you mentioned in an old post that it is m4, and Brindle's blog mentioned there will be a new policy language. So where can I find the source of the existing policies, and when will the new language take over?

3) there's a minor mind leap I saw this command

seinfo -aport_type -x | wc -l

where port_type is an attribute. What's an attribute? I guess it is kind of aggregation of types?

PS: I read almost 80 recent posts last night, I wish I have read your blog many years ago.

1. SELinux rules are between types (or attributes). You have a source type httpd_t representing a process type of in SELinux lingo a "domain". And you have a target type, in this case postgresql_port_t. Then as you properly stated you have the class of the target object and the list of permissions you are granting. In SELinux there is no concept of UID or ownership of an object like there is in DAC (Descretionary Access Control == Linux System APIs)

2 Sources for the policy released productes are included in the SRC RPM. Newer policies are stored in git either Fedora git.fedorahosted.org/git/selinux-policy.git which is based off the refpolicy in http://oss.tresys.com/git/refpolicy.git

3. Attributes as ways of grouping types together so yes thinking of this as a aggregate type of a group. For example all process types have a attribute of "domain". All file types have an attribute of "file_type", and all port types have a attribute of "port_type". These attributes can then be used for writing policy like

allow rpm_t file_type:file manage_file_perms;

equivalent of _db for webports available?

Hi Dan,

Great reading! Is there also an boolean on RHEL 6 to have something like this httpd_can_network_connect_web. So the webserver is only allowed to connect to other webports (eg. 80,443,8080,8443). This is handy when using payment provider scripts and stuff like REST. Currently I use httpd_can_network_connect only for this reason.


Re: equivalent of _db for webports available?

sesearch -A -b httpd_can_network_relay -s httpd_t -p name_connect
Found 7 semantic av rules:
allow httpd_t squid_port_t : tcp_socket name_connect ;
allow httpd_t memcache_port_t : tcp_socket name_connect ;
allow httpd_t gopher_port_t : tcp_socket name_connect ;
allow httpd_t ephemeral_port_type : tcp_socket name_connect ;
allow httpd_t ftp_port_t : tcp_socket name_connect ;
allow httpd_t http_cache_port_t : tcp_socket name_connect ;
allow httpd_t http_port_t : tcp_socket name_connect ;

Is the closest. If you run your avc's for a blocked connection in RHEL7 and Latest Fedora's it will tell you if a boolean would allow the access. Also setroubleshoot should tell you the name of the booleans in RHEL6.

Re: equivalent of _db for webports available?


I enabled the httpd_can_network_connect_relay boolean but then a remote connection fails with:

type=AVC msg=audit(1369915326.405:289991): avc: denied { name_connect } for pid=3030 comm="php-cgi" dest=80 scontext=system_u:system_r:httpd_sys_script_t:s0 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket
type=SYSCALL msg=audit(1369915326.405:289991): arch=c000003e syscall=42 success=no exit=-13 a0=6 a1=7fffbe6978a0 a2=10 a3=0 items=0 ppid=25932 pid=3030 auid=0 uid=10106 gid=505 euid=10106 suid=10106 fsuid=10106 egid=505 sgid=505 fsgid=505 tty=(none) ses=20175 comm="php-cgi" exe="/usr/bin/php-cgi" subj=system_u:system_r:httpd_sys_script_t:s0 key=(null)

Any clue?

Re: equivalent of _db for webports available?

Well it looks like we treat cgi scripts that run under httpd_t differently for this boolean.

sesearch -CA -s httpd_sys_script_t -t http_port_t -p name_connect
Found 3 semantic av rules:
DT allow httpd_script_type reserved_port_type : tcp_socket name_connect ; [ httpd_enable_cgi nis_enabled && ]
DT allow nsswitch_domain reserved_port_type : tcp_socket name_connect ; [ nis_enabled ]
DT allow httpd_sys_script_t port_type : tcp_socket { recv_msg send_msg name_connect } ; [ httpd_enable_cgi httpd_can_network_connect && ]

Which means the best boolean that will get you what you want is httpd_can_network_connect.

nis_enabled should only be used in an NIS environment, since it is really loose.

Another tighter option would be to build a custom policy module using audit2allow.

# grep httpd_sys_script_t /var/log/audit/audit.log | audit2allow -M myhttpd
# semodule -i myhttpd.pp

This would modify policy to allow cgi scripts to connect to only the httpd ports.

The other advanced option would be to use sepolgen or sepolicy generate --cgi to create policy for you cgi script.

Re: equivalent of _db for webports available?

Works now :-) Will sesearch be backported to EL 6.4 too? Seems a handy tool!

Re: equivalent of _db for webports available?

It is in there, setools-cmdline package, might not be in primary RHEL packages.

  • 1

Log in