removing unmaintained selinux code

[Paweł Hajdan, Jr.]

I'd like to remove CHROMIUM_SELINUX code behind the selinux gyp flag.

It used to work, but recently became broken to the degree of failing to compile.

I haven't seen much usage of it.

Are there any objections to the removal?

Paweł

[Mike Frysinger]

sounds like a Q for the new chromium-packagers list :)

i'd think Fedora/RedHat might care enough to fix it ...

-mike

[Adam Langley]

On Wed, May 1, 2013 at 5:39 PM, Paweł Hajdan, Jr.
<phajd...@chromium.org> wrote:

> I'd like to remove CHROMIUM_SELINUX code behind the selinux gyp flag.

I wrote that code and I strongly endorse its death.

It caused the renderers to do a dynamic type transition to another
SELinux type. I don't think anything ended up using it.


Cheers

AGL

[Julien Tinnes]

Yeah it would be nice to not have to maintain this. Adam: you mean
Chromium in Fedora doesn't install you SELinux policy ?
If there is no objection, let's remove sandbox/linux/selinux as well
in that case.

Julien

PS: I actually fixed that compilation issue yesterday
(https://chromiumcodereview.appspot.com/14579002/).

[Adam Langley]

On Wed, May 1, 2013 at 6:22 PM, Julien Tinnes <j...@chromium.org> wrote:
> Yeah it would be nice to not have to maintain this. Adam: you mean
> Chromium in Fedora doesn't install you SELinux policy ?

I think they transition based on exec.

> If there is no objection, let's remove sandbox/linux/selinux as well
> in that case.

Good idea.



Cheers

AGL

[Paweł Hajdan, Jr.]

Responding to some questions here:

1. Why not chromium-packagers? Because the only distro using that option was Gentoo.

2. Fedora/RedHat doesn't use the super-simple policy from our tree. Gentoo uses http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-refpolicy.git;a=blob;f=policy/modules/contrib/chromium.te;h=ec816e4dcc16db3f4160f89c0e68fbb21746f69a;hb=HEAD and Fedora/RedHat has some policy for Google Chrome that broke it a few times.

Paweł

[Julien Tinnes]

So it looks like Gentoo is actually using chromium_renderer_t, no ?
Does gentoo use the setuid sandbox and seccomp-bpf as well ? If yes,
I'm not worried, but if no, I don't think this policy is nearly tight
enough.

Julien

[Paweł Hajdan, Jr.]

On Thu, May 2, 2013 at 12:16 PM, Julien Tinnes <j...@chromium.org> wrote:

So it looks like Gentoo is actually using chromium_renderer_t, no ?

It used to, but no longer does.

 

Does gentoo use the setuid sandbox and seccomp-bpf as well ?

Now - yes. Previously it wouldn't when SELinux mode was enabled. Note this is not the default on Gentoo.

 

If yes, I'm not worried, but if no, I don't think this policy is nearly tight enough.

Interesting - I'd like to learn more. Could you comment inline about the policy there - which entries seem too broad?

########################################
#
# chromium_renderer local policy
#

allow chromium_renderer_t self:process execmem;

allow chromium_renderer_t self:fifo_file rw_fifo_file_perms;
allow chromium_renderer_t self:shm create_shm_perms;
allow chromium_renderer_t self:unix_dgram_socket { create read sendto };
allow chromium_renderer_t self:unix_stream_socket { create getattr read write };

allow chromium_renderer_t chromium_t:fd use;
allow chromium_renderer_t chromium_t:unix_stream_socket rw_stream_socket_perms;
allow chromium_renderer_t chromium_tmpfs_t:file rw_file_perms;

dontaudit chromium_renderer_t chromium_t:dir search;	# /proc/... access
dontaudit chromium_renderer_t self:process getsched;

read_files_pattern(chromium_renderer_t, chromium_xdg_config_t, chromium_xdg_config_t)

rw_fifo_files_pattern(chromium_renderer_t, chromium_tmp_t, chromium_tmp_t)

dev_read_urand(chromium_renderer_t)

files_dontaudit_list_tmp(chromium_renderer_t)
files_dontaudit_read_etc_files(chromium_renderer_t)
files_search_var(chromium_renderer_t)

init_sigchld(chromium_renderer_t)

miscfiles_read_localization(chromium_renderer_t)

userdom_dontaudit_use_all_users_fds(chromium_renderer_t)
userdom_use_user_terminals(chromium_renderer_t)

xdg_read_config_home_files(chromium_renderer_t)

xserver_user_x_domain_template(chromium_renderer, chromium_renderer_t, chromium_tmpfs_t)

tunable_policy(`chromium_read_system_info',`
	kernel_read_kernel_sysctls(chromium_renderer_t)
	kernel_read_system_state(chromium_renderer_t)
',`
	kernel_dontaudit_read_kernel_sysctls(chromium_renderer_t)
	kernel_dontaudit_read_system_state(chromium_renderer_t)
')

[Julien Tinnes]

On Thu, May 2, 2013 at 12:36 PM, Paweł Hajdan, Jr.
<phajd...@chromium.org> wrote:
> On Thu, May 2, 2013 at 12:16 PM, Julien Tinnes <j...@chromium.org> wrote:
>> Does gentoo use the setuid sandbox and seccomp-bpf as well ?
> Now - yes. Previously it wouldn't when SELinux mode was enabled. Note this
> is not the default on Gentoo.

Which is one is the default ? I couldn't tell if it's SELinux or
setuid + seccomp-bpf.
If you can, please make the latter the default. It's more secure, and
actively developed (you can throw SELinux on top of course!). If the
default could show "adequately sandboxed" in about:sandbox, that would
be great.

>> If yes, I'm not worried, but if no, I don't think this policy is nearly
>> tight enough.

The largest issue is that you have no sandbox for anything not started
from the Zygote (such as the GPU process).

For Zygote process types (renderers / workers):
- doesn't this policy allow to access anything in /tmp? (or is it only
r/w existing file descriptors?)
- to directly communicate with the X server?
- can't you access all of /proc?

Julien

[Paweł Hajdan, Jr.]

On Thu, May 2, 2013 at 7:16 PM, Julien Tinnes <j...@chromium.org> wrote:

On Thu, May 2, 2013 at 12:36 PM, Paweł Hajdan, Jr.
<phajd...@chromium.org> wrote:
> On Thu, May 2, 2013 at 12:16 PM, Julien Tinnes <j...@chromium.org> wrote:

>> Does gentoo use the setuid sandbox and seccomp-bpf as well ?
> Now - yes. Previously it wouldn't when SELinux mode was enabled. Note this
> is not the default on Gentoo.

Which is one is the default ? I couldn't tell if it's SELinux or
setuid + seccomp-bpf.

Ah right, the default was always setuid + seccomp-bpf.

 

If you can, please make the latter the default. It's more secure, and
actively developed (you can throw SELinux on top of course!). If the
default could show "adequately sandboxed" in about:sandbox, that would
be great.

It does - just to confirm.

 

>> If yes, I'm not worried, but if no, I don't think this policy is nearly
>> tight enough.

The largest issue is that you have no sandbox for anything not started
from the Zygote (such as the GPU process).

Makes sense - I was actually thinking about adding a type transition for these other processes, which I think would help with the above - it's just a small number of users of the SELinux sandbox and a difficulty of testing SELinux-based things on my main machine that made me rather go in the direction of removal.

 

For Zygote process types (renderers / workers):
- doesn't this policy allow to access anything in /tmp? (or is it only
r/w existing file descriptors?)

I think with SELinux file contexts this will only allow access to Chromium-made temporary files (and any Chromium temporary files will be marked as such and not accessible by other apps).

 

- to directly communicate with the X server?

That's what it does - last time I checked it was needed to get it to work. I think the process does the same thing under suid/seccomp-bpf sandbox, it could be just hidden because of checks being done only at open time for DAC versus always on MAC.

 

- can't you access all of /proc?

I think in refpolicy access to /proc is divided into some categories - I don't think it allows access to all of /proc, and it's configurable by a SELinux boolean.

Paweł