On 06/11/2013 05:11 AM, Thomas COUDRAY wrote:
Yes, this is true.
$ adb shell su 0 cat /seapp_contexts | grep levelFrom
user=_app seinfo=container domain=container_app type=container_app_data_file
levelFrom=container sdcard=/mnt_1/sdcard_ sdcardSuffix=_container
Yes, so that reflects their own modifications to libselinux (and to the
install-time MAC code) to support the levelFrom=container and sdcard
constructs.
This is what I did.
But when I enabled logging from kernel config (i.e: CONFIG_AUDIT=y and
CONFIG_AUDITSYSCALL=y),
there was no selinux|avc logs from dmesg & /proc/kmsg, and nothing in
/data/misc/audit/.
When I boot in enforcing mode, SElinux works great: I have some legit
access denied.
The kernel sources that I saw had a CONFIG_PROC_AVC option that if
enabled, would log the audit messages via a /proc/avc_msg node. The
kernel had a modified version of kernel/audit.c that sends the audit
messages there rather than calling printk if there is no auditd.
Personally, I would just revert that change so they appear in dmesg or
build and run auditd so that they go to /data/misc/audit/audit.log. But
you could try enabling that option and then reading from /proc/avc_msg.
I will define a separate TE domain for my app.
But how can I link my new domain policy, with the samsung sepolicy ?
I have to port semodule(8) into my device, or can I get the /sepolicy
file from my device to my computer and link with my new .pp using
semodule_link(8) and flash back onto my device ? I think none of these
solutions works.
Correct. We chose monolithic policy rather than modular policy for SE
for Android, for a number of reasons, including minimizing our userspace
footprint and avoiding any LGPL or GPL userspace dependencies. So if
you want to use the existing GS4 policy, then you are limited in what
you can change. You can easily create modified copies of
mac_permissions.xml, file_contexts, property_contexts, and
seapp_contexts, but you can't modify sepolicy without rebuilding from
source, and I don't believe source is available for their policy. So
you could for example easily enable separation among third party apps by
adding levelFrom=app to the line for user=_app domain=untrusted_app
type=app_data_file and replacing /seapp_contexts or dropping the
modified file under /data/security and performing a setprop
selinux.reload_policy 1. But defining a new domain will be more difficult.
If you truly want to define new domains, then I think you'll have to
take our source policy and try to build it up to include the new domains
and types they added so that you can rebuild from source. You can
extract information from the GS4 sepolicy via the setools package (yum
install setools* on Fedora), particularly the seinfo and sesearch
commands, and can even generate a semantic diff between their policy and
another policy such as ours using sediff (unfortunately not in a form
though that you can just apply as a patch). Note however that as their
policy was forked from ours at some point in the past, some of the
differences will be changes we made since they forked rather than
changes they made. There is also a "dispol" program in checkpolicy
(installed as sedispol on Fedora) that is a developer debugging tool
that supports (partial) disassembly of a binary policy.
--
This message was distributed to subscribers of the seandroid-list mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe seandroid-list" without quotes as the message.
