crash is in memd

This is a bit mysterious.  There is also this kind of crash.

https://crash.corp.google.com/browse?q=&stbtiq=memd&reportid=b9787e88fab1f18a&index=0

with this attached log:

type=1400  avc:  granted  { execute } for  pid=2312 comm="minijail0" name="memd" dev="dm-0" ino=95079 scontext=u:r:minijail:s0 tcontext=u:object_r:cros_unconfined_exec:s0 tclass=file

but that doesn't look like an error message---in fact it sounds rather positive.

Annoyingly, all of those reports (afaict) didn't get the kernel version.

Also, are we messing up the signature in these reports?  If they get spread over a lot of different signatures, we won't notice the severity (I wonder if this happened here).

Get rekt indeed!

Qijiang, you've made some changes that affect those signatures.  Can you help explain what goes on here?  Thanks!

https://chromium-review.googlesource.com/1163411

Incidentally, those changes went in shortly before R70 forked.

Actually, may I assign this to you for the time being?  I am hoping you can add some explanation and more details on this failure, and assign it back to me.  Thanks!

selinux "granted" audit reports aren't crashes, they're advisory that we need to update selinux policy.  fqj@ has been handling that so far.

M72 removed most of grants to be audited.

These grants were used to discover unconfined operations (many execute/file creation/transition) on different boards.
These unconfined allows will either be confined (for example, what's in this bug should be allowed and transited to a different domain instead of staying at minijail), or denied (for example, many dac_override).

It turns out to be too noisy (especially for dev image since it doesn't sample 0.1% before collection) to collect these information until we confined most of stuffs.


Mike,
Do you think whether it's necessary to cherry-pick these "removal" to stable? FYI: user selinux "crashes" are sampled at 0.1%.
It's going to take some human work to handle many merge conflicts by only cherry-picking some changes since SEPolicy is actively being developed.

if it's resolved in R72, imo that's fine. it has already branched, so there's pressure to not make changes to R71 or older unless necessary.

just talk to the TPMs and let them know which reports in R71 they can effectively ignore.

#8 for my benefit, what are these "unconfined operations"?  Do you have other more descriptive bugs or docs you can point me to?  Thanks!

unconfined operations means:
1) we haven't worked that far to reach this process/domain.
2) we didn't see this on betty, betty-arcnext, or kevin. meaning this is something only on some boards.

"minijail execute memed" is obviously case (1), which is partially confined in M72 (transition rule confined, other permissions not)

Also we masked a lot of auditallow in M72 so case (1) won't trigger any spams for non-SELinux-rule developer, since the auditallow is mostly used to discover case (2), to reduce the chance of breaking things before putting something enforced.

Unfortunately there's no more descriptive bugs for unconfined domains, because unconfined here means "we haven't worked that far or we didn't see it on either betty/betty-arcnext or kevin"

Issue 915798 has been merged into this issue.