| 1 |
On Tue, Apr 17, 2012 at 03:26:42PM +0200, "Paweł Hajdan, Jr." wrote: |
| 2 |
> What are next steps here? Previous e-mails in this thread contain |
| 3 |
> suggested policy, and now chromium version with selinux support is in |
| 4 |
> tree (hard masked). |
| 5 |
|
| 6 |
As said on IRC (and per your suggestion), yes, a bugreport would do nicely |
| 7 |
here (mailing to inform others that might be watching ;) |
| 8 |
|
| 9 |
> On #gentoo-hardened I received comments about unconfined_t usage in the |
| 10 |
> policy, but I'd really like to keep the main browser process unconfined |
| 11 |
> (see also <http://danwalsh.livejournal.com/15700.html>, and I don't want |
| 12 |
> to create as complicated policy for chromium like the reference mozilla |
| 13 |
> policy). |
| 14 |
|
| 15 |
I don't like dynamic transitions, let alone from unconfined. It's way more |
| 16 |
"proper" to use a real application domain (even though that domain can still |
| 17 |
be marked as unconfined for policies that support unconfined) and support |
| 18 |
transitions (like is done with mozilla and mozilla_plugin_t). |
| 19 |
|
| 20 |
But I don't think it'll be hard to develop a chrome module. I might do it |
| 21 |
just to make better documentation on how to develop modules yourself. |
| 22 |
|
| 23 |
Wkr, |
| 24 |
Sven Vermeulen |
Archives