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

Issue 791626 link

Starred by 0 users

Issue metadata

Status: Fixed
Owner:
Last visit 29 days ago
Closed: May 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Feature



Sign in to add a comment

crash-reporter: integrate selinux audit logging

Project Member Reported by vapier@chromium.org, Dec 4 2017

Issue description

currently selinux audit messages are going untriaged.  lets fix that.

we've got some issues where this is coming up (like issue 727889).  unrelated example output from my eve right now:
2017-12-03T11:31:19.411426-08:00 NOTICE kernel: [36118.785474] audit: type=1400 audit(1512329479.410:511): avc:  denied  { search } for  pid=22421 comm="Binder:6153_2" name="5252" dev="proc" ino=445173 scontext=u:r:priv_app:s0:c512,c768 tcontext=u:r:zygote:s0 tclass=dir permissive=0
2017-12-03T11:31:19.431413-08:00 NOTICE kernel: [36118.804661] audit: type=1400 audit(1512329479.430:512): avc:  denied  { read } for  pid=22421 comm="Binder:6153_2" name="/" dev="tmpfs" ino=16434 scontext=u:r:priv_app:s0:c512,c768 tcontext=u:object_r:device:s0 tclass=dir permissive=0
2017-12-03T13:13:04.430853-08:00 NOTICE kernel: [36566.395630] audit: type=1400 audit(1512335584.429:514): avc:  denied  { dac_read_search } for  pid=21475 comm="main" capability=2  scontext=u:r:zygote:s0 tcontext=u:r:zygote:s0 tclass=capability permissive=0

if we were to watch the logs for these lines and create a simple report, that'd be easy.  but in order to make them actionable, we need to log quite a bit more.  the question is, what would be needed here ?  by the time the audit hit the log, the process in question has already moved on.  so scraping info from /proc/$pid/ wouldn't be super helpful.

is it possible to change selinux behavior so that it'll trigger a crash whenever a deny is hit ?  we could add a crosh knob to control this, and make it so that test/canary images operate in this mode.

any other thoughts ?
 

Comment 1 Deleted

Cc: lhchavez@chromium.org allenwebb@chromium.org
Jorge mentioned that there might be some kernel option/setting we can turn on here to make the logs more useful

Comment 3 Deleted

More specifically, I recall Luis or somebody else landing a change to quiet the audit logs on the Chrome OS side (and maybe a kernel config like CONFIG_ARC_DEVEL or something?)
The change I did was just avoiding printing any permissive=1 logs, even if they would be normally printed in a stock kernel. It unfortunately doesn't make it any more useful :/

There is one change that increases debuggability: https://crrev.com/c/329964 . Re: what more information we want, grabbing the registers seems like a good first step, and that change does exactly that. Maybe also some mapping information so we can get the instruction that caused the denial? Maybe even something like a minidump? (although that one sounds like it's going to be very complicated to gather).

Re: /proc/$pid scraping, SELinux denials don't cause process termination (they make that operation fail with EPERM instead), so it might work for a good chunk of the cases.
Hmmm so maybe I was confused here, and the lines in OP are really what we have. One thing to strongly consider is the possibility of running audit2allow on those lines to turn them from audit logs to SELinux policy lines.
Project Member

Comment 7 by bugdroid1@chromium.org, Mar 14 2018

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

commit 99e4ed7c4bac23c3c0833813db5cd9a69eda63a8
Author: Qijiang Fan <fqj@chromium.org>
Date: Wed Mar 14 11:07:00 2018

crash: move default rule of anomaly collector to below.

BUG= chromium:791626 
TEST=build and run test script.
Change-Id: Ic8e3aa31fb4d9545f0c42cf81941ff049e69fdbc
Reviewed-on: https://chromium-review.googlesource.com/959842
Commit-Ready: Qijiang Fan <fqj@chromium.org>
Tested-by: Qijiang Fan <fqj@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/99e4ed7c4bac23c3c0833813db5cd9a69eda63a8/crash-reporter/anomaly_collector.l

Comment 8 by jeffv@google.com, Apr 4 2018

FYI, the denials in comment #1 are b/72749888.
Project Member

Comment 9 by bugdroid1@chromium.org, May 8 2018

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

commit 7b644a816ebb2f7b499744c3050f1af481291d08
Author: Qijiang Fan <fqj@chromium.org>
Date: Tue May 08 03:46:01 2018

crash: Crash reporting for SELinux violations.

 * Anomaly collector from /var/log/messages to collect SELinux
violation entries.
 * Crash reporter to save the SELinux violation collected to
crash report.

BUG= chromium:791626 ,b:73792432
TEST=build, run tests and test in dev device.

Change-Id: Ic80446b0afb267ffdf1eede0ed55520588731698
Reviewed-on: https://chromium-review.googlesource.com/954887
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Qijiang Fan <fqj@google.com>
Reviewed-by: Ben Chan <benchan@chromium.org>

[modify] https://crrev.com/7b644a816ebb2f7b499744c3050f1af481291d08/crash-reporter/crash_reporter.cc
[add] https://crrev.com/7b644a816ebb2f7b499744c3050f1af481291d08/crash-reporter/selinux_violation_collector.h
[modify] https://crrev.com/7b644a816ebb2f7b499744c3050f1af481291d08/crash-reporter/anomaly_collector_test.sh
[add] https://crrev.com/7b644a816ebb2f7b499744c3050f1af481291d08/crash-reporter/selinux_violation_collector.cc
[add] https://crrev.com/7b644a816ebb2f7b499744c3050f1af481291d08/crash-reporter/selinux_violation_collector_test.cc
[modify] https://crrev.com/7b644a816ebb2f7b499744c3050f1af481291d08/crash-reporter/anomaly_collector.l
[modify] https://crrev.com/7b644a816ebb2f7b499744c3050f1af481291d08/crash-reporter/crash-reporter.gyp
[add] https://crrev.com/7b644a816ebb2f7b499744c3050f1af481291d08/crash-reporter/TEST_SELINUX

Does this need more work?
Owner: f...@chromium.org
Status: Fixed (was: Available)
support is basically merged now, albeit off until we can sort out issue 842751 is sorted out.  i don't think we need this bug anymore though.

Sign in to add a comment