On 4/10/12 7:46 PM, Sven Vermeulen wrote:
> The policy itself is currently written (or generated?) with raw allow rules
Thank you for taking a look.
The policy is written from scratch, using audit2allow to add rules, but
I was careful to always test in enforcing mode, and to only grant what's
needed (i.e. verifying that without given rule the browser would break).
> which, given prior experience, probably means you also want (or need) to
> dev_read_rand(chromium_renderer_t)
> as well ;-)
dev_read_rand won't be needed. It's quite interesting, because I was
writing that part of code when porting the browser to Linux. It only
uses /dev/urandom.
> Do you feel up to updating the policy to reflect the style of refpolicy? If
> not, I don't mind taking a stab at it myself.
See attached version, I updated all places I could and verified it still
works.
Note that to test you'd need SELinux-aware chromium, which I've not yet
checked to cvs (I'll do that as soon as upstream releases official 20.x
version).
> However, besides the style, it also looks like the module is quite
> incomplete. It only defines the chromium_renderer_t, but how would chrome
> ever be able to "transition" to this domain? There is no transition rule
> declared, nor any files that could behave as entry points for the domain.
The browser uses setcon, see SELinuxTransitionToTypeOrDie in Chromium
codebase (cs.chromium.org),
<http://code.google.com/searchframe#OAMlx_jo-ck/src/content/browser/zygote_main_linux.cc&exact_package=chromium&q=setc on&type=cs&l=72>
> I would also expect that, if it is for chromium, there would be a chromium_t
> domain as well. Or in other words:
>
> - a user calls chromium (labeled "chromium_exec_t")
> - a transition occurs from user_t to chromium_t
> - chromium calls some binary for rendering (or is SELinux-aware and
> does it by itself)
> - a transition occurs from chromium_t to chromium_renderer_t
> - etc.
Chromium can be compiled to be SELinux-aware, and it forks itself (and
doesn't call exec - so that the underlying files can be updated in-place
without disrupting running browsers; this is because Chromium has
multi-process architecture and browser<->renderer IPC protocol changes
between versions).
> The use of "dyntransition" is frowned upon as it is much more "lax" than a
> regular transition.
I've heard about that. I'm not aware of any better option for chromium
though, especially that it can't really use exec, only fork.
policy_module(chromium-browser, 1.0.0)
gen_require(`
type unconfined_t;
type user_tmpfs_t;
role unconfined_r;
')
type chromium_renderer_t;
domain_base_type(chromium_renderer_t)
role unconfined_r types chromium_renderer_t;
dyntrans_pattern(unconfined_t, chromium_renderer_t);
allow chromium_renderer_t self:fifo_file rw_fifo_file_perms;
allow chromium_renderer_t self
rocess execmem;
allow chromium_renderer_t self:shm { create destroy read write unix_read unix_write };
allow chromium_renderer_t self:unix_dgram_socket { create read sendto };
allow chromium_renderer_t self:unix_stream_socket { create getattr read };
allow chromium_renderer_t unconfined_t:unix_stream_socket rw_stream_socket_perms;
allow chromium_renderer_t user_tmpfs_t:file { read getattr append };
dev_read_urand(chromium_renderer_t);
files_list_tmp(chromium_renderer_t);
fs_rw_tmpfs_files(chromium_renderer_t);
miscfiles_read_localization(chromium_renderer_t);
miscfiles_read_fonts(chromium_renderer_t);
unconfined_use_fds(chromium_renderer_t);
xdg_read_generic_config_home_files(chromium_render er_t);
www-client/chromium SELinux sandbox
