On 07/29/2016 02:38 PM, Stephen Smalley wrote:
On 07/29/2016 08:14 AM, peter enderborg wrote:
On 07/28/2016 07:19 PM, Stephen Smalley wrote:
On 07/28/2016 12:11 PM, peter enderborg wrote:
What is the point with that?
Can you explain a bit further what specific problem you are
encountering, and with which branch/release of AOSP?
Hi Stephen.
I read your response that it is a not wanted behaviour.
The release is
build/core/build_id.mk:export BUILD_ID=NRD90M
I got:
libsepol.report_failure: neverallow on line 162 of
system/sepolicy/domain.te (or line 8850 of policy.conf) violated by
allow ppsys ppsys:capability { sys_ptrace };
Line 8850 is:
# Limit ability to ptrace or read sensitive /proc/pid files of processes
# with other UIDs to these whitelisted domains.
neverallow {
domain
-debuggerd
-vold
-dumpstate
-system_server
-perfprofd
} self:capability sys_ptrace;
and my te is:
type ppsys_exec, exec_type, file_type;
userdebug_or_eng(`
type ppsys, domain, mlstrustedsubject;
init_daemon_domain(ppsys)
allow ppsys self:capability sys_ptrace;
')
A removal of the line 'allow ppsys self:capability sys_ptrace', the make
completes with a runnable image.
Ok, that makes sense, and it isn't anything new - you should have
encountered the same issue as early as 5.0 Lollipop. That's why I asked
for more details, because I wasn't clear on why this would be a new issue.
Well, something is new since the problem was not there before. Something with
mlstrustedobjects?
You'll note that in the source neverallow statement in
system/sepolicy/domain.te there is an exception for perfprofd that is
wrapped in a userdebug_or_eng() macro:
Vendors does not need to debug or what? I have created
https://android-review.googlesource.com/#/c/252242/
for sys_ptrace to be free to use on debug builds.
# Limit ability to ptrace or read sensitive /proc/pid files of processes
# with other UIDs to these whitelisted domains.
neverallow {
domain
-debuggerd
-vold
-dumpstate
-system_server
userdebug_or_eng(`-perfprofd')
} self:capability sys_ptrace;
You could add a similar exception for ppsys if you are willing to modify
system/sepolicy files, but I don't know if that is viewed as permissible
in your environment.
Changes in system/sepolicy is far more problematic than Roberts concern
than the difference on different builds. I agree with the goal, but I
have complete different conclusion, permissive that is really
a difference on user versus debug variants and make it a huge task
to track down domains that exist in both but has different permissions
on user vs debug variants. Obviously someone sees the need for
system monitoring tools to use this sys_ptrace for debug variants
so why only perfprofd be the only allowed tool?
Otherwise, I think your only option if ppsys truly requires this
permission would be to make it a permissive domain, i.e. add:
permissive ppsys;
inside of your userdebug_or_eng() block in your .te file.
You can suppress avc messages regarding it in the same manner as
system/sepolicy/su.te - just clone the dontaudit rules from there (maybe
those should be put into a macro that can be called by any domain). Or
you could just specifically dontaudit ppsys self:capability sys_ptrace;
if that is the only one of concern.
Perhaps you are suggesting that all of the neverallows in
system/sepolicy should be wrapped so that they are only included in user
builds? I think Bill's concern would apply there - that would increase
Very much for debug stuff like sys_ptrace and ptrace, it is very strange
that there is debug restrictions on debug and eng builds. It only make
people to invent far more risky workarounds. And in my case it's only about
reading in /proc/pids.
the delta between user and userdebug builds and cause many violations to
remain undetected until late in the development cycle, when it will be
harder to resolve them. Better to make domains that will only exist in
userdebug/eng builds permissive, since those won't matter in the user
builds anyway.
_______________________________________________
Seandroid-list mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to
[email protected].
