| 1 |
On 4/10/12 7:46 PM, Sven Vermeulen wrote: |
| 2 |
> The policy itself is currently written (or generated?) with raw allow rules |
| 3 |
|
| 4 |
Thank you for taking a look. |
| 5 |
|
| 6 |
The policy is written from scratch, using audit2allow to add rules, but |
| 7 |
I was careful to always test in enforcing mode, and to only grant what's |
| 8 |
needed (i.e. verifying that without given rule the browser would break). |
| 9 |
|
| 10 |
> which, given prior experience, probably means you also want (or need) to |
| 11 |
> dev_read_rand(chromium_renderer_t) |
| 12 |
> as well ;-) |
| 13 |
|
| 14 |
dev_read_rand won't be needed. It's quite interesting, because I was |
| 15 |
writing that part of code when porting the browser to Linux. It only |
| 16 |
uses /dev/urandom. |
| 17 |
|
| 18 |
> Do you feel up to updating the policy to reflect the style of refpolicy? If |
| 19 |
> not, I don't mind taking a stab at it myself. |
| 20 |
|
| 21 |
See attached version, I updated all places I could and verified it still |
| 22 |
works. |
| 23 |
|
| 24 |
Note that to test you'd need SELinux-aware chromium, which I've not yet |
| 25 |
checked to cvs (I'll do that as soon as upstream releases official 20.x |
| 26 |
version). |
| 27 |
|
| 28 |
> However, besides the style, it also looks like the module is quite |
| 29 |
> incomplete. It only defines the chromium_renderer_t, but how would chrome |
| 30 |
> ever be able to "transition" to this domain? There is no transition rule |
| 31 |
> declared, nor any files that could behave as entry points for the domain. |
| 32 |
|
| 33 |
The browser uses setcon, see SELinuxTransitionToTypeOrDie in Chromium |
| 34 |
codebase (cs.chromium.org), |
| 35 |
<http://code.google.com/searchframe#OAMlx_jo-ck/src/content/browser/zygote_main_linux.cc&exact_package=chromium&q=setcon&type=cs&l=72> |
| 36 |
|
| 37 |
> I would also expect that, if it is for chromium, there would be a chromium_t |
| 38 |
> domain as well. Or in other words: |
| 39 |
> |
| 40 |
> - a user calls chromium (labeled "chromium_exec_t") |
| 41 |
> - a transition occurs from user_t to chromium_t |
| 42 |
> - chromium calls some binary for rendering (or is SELinux-aware and |
| 43 |
> does it by itself) |
| 44 |
> - a transition occurs from chromium_t to chromium_renderer_t |
| 45 |
> - etc. |
| 46 |
|
| 47 |
Chromium can be compiled to be SELinux-aware, and it forks itself (and |
| 48 |
doesn't call exec - so that the underlying files can be updated in-place |
| 49 |
without disrupting running browsers; this is because Chromium has |
| 50 |
multi-process architecture and browser<->renderer IPC protocol changes |
| 51 |
between versions). |
| 52 |
|
| 53 |
> The use of "dyntransition" is frowned upon as it is much more "lax" than a |
| 54 |
> regular transition. |
| 55 |
|
| 56 |
I've heard about that. I'm not aware of any better option for chromium |
| 57 |
though, especially that it can't really use exec, only fork. |
Archives