New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 874980 link

Starred by 1 user
Status: Fixed
Owner:
█ f...@chromium.org
Last visit 29 days ago
Closed: Sep 26
Cc:
vapier@chromium.org
kroot@chromium.org
█ kirtika@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug



Sign in to add a comment

selinux is blocking things outside of the ARC++ container

Project Member Reported by vapier@chromium.org, Aug 16 
this no longer works after recent selinux changes:
# mkdir /foo
mkdir: cannot create directory '/foo': Permission denied
# dmesg -c | tail -1
[610750.874961] audit: type=1400 audit(1534442164.718:143): avc:  denied  { associate } for  pid=13038 comm="mkdir" name="foo" scontext=u:object_r:rootfs:s0 tcontext=u:object_r:labeledfs:s0 tclass=filesystem permissive=0

rolling out selinux updates have been fine as long as they only applied to ARC++ or were in permissive mode outside of the ARC++ container.  however, we cannot deploy anything restrictive as long as (1) no one in the wider CrOS team has been made aware of this and (2) there is zero documentation on selinux+CrOS.

Comment 1 by f...@chromium.org, Sep 20

Status: Started (was: Assigned)
Sorry for the late reply.

I didn't see this since most of my bugs are tracked at b/

Currently, all Chrome OS processes are running under permissive domain.

This violation is not process related, but general fs related. It can't separate in-or-out of a container since they share the same kernel. The kernel denied adding rootfs label to a file under labeledfs filesystem (no matter by which process). In general we don't put fs type permissive, since it opens holes to label file under any fs to that label.

The violation is generated recently by label Chrome OS / to rootfs. When you try to create a file, kernel will inheritance the parent file label by default (rootfs), and associate it current fs (labeledfs).
There's no existing rule allowing this since in user world rootfs (I only mean /[^/]*, not data in any sub-directory) is general immutable.

I'll add an allow rule to allow this at current stage so it doesn't influence developer process, before we confined the developer use process (subprocess of ssh, and frecon).


Regarding wider CrOS team, and documents, we'll compile a document on how-it-works and troubleshooting at the end of this year or Q1 next year.

Comment 2 by f...@chromium.org, Sep 20 

s/documents/documentation/
Project Member

Comment 3 by bugdroid1@chromium.org, Sep 20 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform2/+/dd82cdb1ca9b8bbb97397a919567a227c406bce4

commit dd82cdb1ca9b8bbb97397a919567a227c406bce4
Author: Qijiang Fan <fqj@chromium.org>
Date: Thu Sep 20 18:39:48 2018

sepolicy: temporarily allow rootfs to associate to labeledfs.

BUG= chromium:874980 
TEST=mkdir /foo on betty (ARC N boards)

Change-Id: I9015b0c11bfefd00b309ceab920eadd9c519febd
Reviewed-on: https://chromium-review.googlesource.com/1235434
Commit-Ready: Qijiang Fan <fqj@google.com>
Tested-by: Qijiang Fan <fqj@google.com>
Reviewed-by: Kenny Root <kroot@google.com>

[modify] https://crrev.com/dd82cdb1ca9b8bbb97397a919567a227c406bce4/sepolicy/policy/chromeos/file.te

Comment 4 by vapier@chromium.org, Sep 20 

when we have documentation/tooling in place and have made developers aware, i think we're happy with rolling out selinux to CrOS more widely to make the default behavior more restrictive

Comment 5 by vapier@chromium.org, Sep 21 

we've got another report of /boot being blocked:
  https://groups.google.com/a/chromium.org/d/topic/chromium-os-dev/aAFOZeDzRkA/discussion

this breaks people trying to use update_kernel.sh when developing.

Comment 6 by f...@chromium.org, Sep 26

Status: Fixed (was: Started)
/boot should be the same reason.

It should now be fixed.
►

Sign in to add a comment