[refpolicy] [PATCH v3 1/3] Support read/append/manage functions for various httpd content

[sven.vermeulen@siphos.be (Sven Vermeulen)]

On Tue, Jun 26, 2012 at 10:04:13AM -0400, Christopher J. PeBenito wrote:
> >>> +interface(`apache_append_all_ra_content_files',`
> >>
> >> Inconsistent interface naming.  I'm ok w/o the _files.
> >>
[...]
> Look closely at the naming of all the additions.  Thats what I meant by inconsistency.  They should have the same pattern.

Ok, it was indeed not consistent. 

May I take this opportunity to get some quick feedback on the interface
naming? From the naming convention [1] URL, it sais that the predicate (end
of the interface name) can be ommitted when it is clear what object is being
referenced.

[1] http://oss.tresys.com/projects/refpolicy/wiki/InterfaceNaming

Most actions against file object classes are possible for many of them
(file, symlink, socket, fifo, block, ...). Would it be a good interpretation
if "apache_append_all_ra_content" matches append rights for the entire
class family, whereas "apache_append_all_ra_content_files" is only for the file
class?

And if it does, is it OK to keep the implementation of said interface as
strict as possible (for as long as it is strictly needed) and enlarge (and
update other policies) when necessary?

For instance (since I know the above paragraph isn't clear): take a look at
"apache_read_all_ra_content", which was suggested with the following:

+interface(`apache_read_all_ra_content',`
+	gen_require(`
+		attribute httpd_ra_content;
+	')
+
+	read_files_pattern($1, httpd_ra_content, httpd_ra_content)
+	read_lnk_files_pattern($1, httpd_ra_content, httpd_ra_content)
+')

Although it can be split easily in "apache_read_all_ra_content_files" and
"apache_read_all_ra_content_symlinks", the notion of having a
"apache_read_all_ra_content" which does it just for files and symlinks might
in the future be 'enlarged' to support say fifo files.

In that case, the policy change might 'update' "apache_read_all_ra_content"
to add in read_fifo_files_pattern to it. Any policy that uses this interface
thus gets more privileges, but *knows* this as it used the more
course-grained interface, rather than coding the _files and _symlinks
interfaces in it.

I don't believe it would be a good idea to immediately "fill up" the
interface, like so:

+interface(`apache_read_all_ra_content',`
+	gen_require(`
+		attribute httpd_ra_content;
+	')
+
+	read_files_pattern($1, httpd_ra_content, httpd_ra_content)
+	read_lnk_files_pattern($1, httpd_ra_content, httpd_ra_content)
+	read_fifo_files_pattern($1, httpd_ra_content, httpd_ra_content)
+	read_sock_files_pattern($1, httpd_ra_content, httpd_ra_content)
+	read_blk_files_pattern($1, httpd_ra_content, httpd_ra_content)
+	read_chr_files_pattern($1, httpd_ra_content, httpd_ra_content)
+	list_dirs_pattern($1, httpd_ra_content, httpd_ra_content)
+')

but then policy editors must be aware that an interface might, in the
future, expand to become more course-grained (within the limits of the
interface).


And while I'm on it, what is the difference between a spec_domtrans and a
regular one? Is that only that the transition doesn't occur automatically
(i.e. the application has to be SELinux-aware to use it)?

Wkr,
	Sven Vermeulen