• 1
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;

  • 1

Log in