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

[cpebenito@tresys.com (Christopher J. PeBenito)]

On 06/26/12 16:38, Sven Vermeulen wrote:
> 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?

I would say apache_append_all_ra_content() works on all typical classes for the content, i.e. dir, file, lnk_file.  If you change it to apache_append_all_ra_content_files(), then you have ra access on files and search (or maybe list) on the dirs.

> 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?

If you make the interface more strict, like apache_append_all_ra_content_files(), the implementation should be strict, so there can be tight least-privilege.  But if you use a more abstract apache_append_all_ra_content(), then we can be a little looser on the least-privilege. 

> 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).

This goes back to knowing something about typical web content.  Definitely not for device nodes.  Probably not for fifo_file and sock_file, but we could be more flexible in adding it if it became necessary.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com