This reverts commit c450759e8e.
There was nothing wrong with this change originally --- the companion
change in init was broken.
Bug: http://b/19702273
Change-Id: I9d806f6ac251734a61aa90c0741bec7118ea0387
The deprecated/deleted usbfs kernel driver gets really unhappy when
SELinux denies it access to directories. On flo (3.4.0 kernel), this
comes across as an SELinux denial followed by a kernel panic.
Steps to reproduce:
1. plug in a USB device.
2. notice nothing happens.
3. unplug the USB device
4. plug it in again, watch for restart.
Expected:
USB device works
Actual:
[329180.030242] Host mode: Set DC level as 0x68 for flo.
[329180.030395] msm_hsusb_host msm_hsusb_host: Qualcomm On-Chip EHCI Host Controller
[329180.030639] Unable to create devices usbfs file
[329180.030944] type=1400 audit(1425327845.292:12): avc: denied { search } for pid=24033 comm="kworker/0:1" name="/" dev="usbfs" ino=291099 scontext=u:r:kernel:s0 tcontext=u:object_r:usbfs:s0 tclass=dir
[329180.060394] msm_hsusb_host msm_hsusb_host: new USB bus registered, assigned bus number 1
[329180.091583] msm_hsusb_host msm_hsusb_host: irq 132, io mem 0x12500000
[deleted]
[329180.120178] hub 1-0:1.0: USB hub found
[329180.120452] hub 1-0:1.0: 1 port detected
[329180.123199] Unable to handle kernel NULL pointer dereference at virtual address 00000070
[329180.123443] pgd = c0004000
[329180.123809] [00000070] *pgd=00000000
[329180.124206] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
[329180.124481] CPU: 0 Tainted: G W (3.4.0-g2e8a935 #1)
[329180.124908] PC is at mutex_lock+0xc/0x48
[329180.125122] LR is at fs_create_file+0x4c/0x128
[329180.125518] pc : [<c0916708>] lr : [<c0440ec4>] psr: a0000013
[deleted]
[329180.281005] [<c0916708>] (mutex_lock+0xc/0x48) from [<c0440ec4>] (fs_create_file+0x4c/0x128)
[329180.281280] [<c0440ec4>] (fs_create_file+0x4c/0x128) from [<c04410c8>] (usbfs_notify+0x84/0x2a8)
[329180.281738] [<c04410c8>] (usbfs_notify+0x84/0x2a8) from [<c009c3b8>] (notifier_call_chain+0x38/0x68)
[329180.282257] [<c009c3b8>] (notifier_call_chain+0x38/0x68) from [<c009c600>] (__blocking_notifier_call_chain+0x44/0x58)
[329180.282745] [<c009c600>] (__blocking_notifier_call_chain+0x44/0x58) from [<c009c628>] (blocking_notifier_call_chain+0x14/0x18)
[329180.283264] [<c009c628>] (blocking_notifier_call_chain+0x14/0x18) from [<c043ef8c>] (generic_probe+0x74/0x84)
[329180.283752] [<c043ef8c>] (generic_probe+0x74/0x84) from [<c04387c4>] (usb_probe_device+0x58/0x68)
[329180.284240] [<c04387c4>] (usb_probe_device+0x58/0x68) from [<c03adc78>] (driver_probe_device+0x148/0x360)
[329180.284576] [<c03adc78>] (driver_probe_device+0x148/0x360) from [<c03ac76c>] (bus_for_each_drv+0x4c/0x84)
[329180.285034] [<c03ac76c>] (bus_for_each_drv+0x4c/0x84) from [<c03adfc8>] (device_attach+0x74/0xa0)
[329180.285522] [<c03adfc8>] (device_attach+0x74/0xa0) from [<c03ac94c>] (bus_probe_device+0x28/0x98)
[329180.286041] [<c03ac94c>] (bus_probe_device+0x28/0x98) from [<c03ab014>] (device_add+0x444/0x5e4)
[329180.286529] [<c03ab014>] (device_add+0x444/0x5e4) from [<c042f180>] (usb_new_device+0x248/0x2e4)
[329180.286804] [<c042f180>] (usb_new_device+0x248/0x2e4) from [<c043472c>] (usb_add_hcd+0x420/0x64c)
[329180.287292] [<c043472c>] (usb_add_hcd+0x420/0x64c) from [<c044600c>] (msm_otg_sm_work+0xe74/0x1774)
[329180.287811] [<c044600c>] (msm_otg_sm_work+0xe74/0x1774) from [<c0091d8c>] (process_one_work+0x280/0x488)
[329180.288299] [<c0091d8c>] (process_one_work+0x280/0x488) from [<c00921a8>] (worker_thread+0x214/0x3b4)
[329180.288787] [<c00921a8>] (worker_thread+0x214/0x3b4) from [<c0096b14>] (kthread+0x84/0x90)
[329180.289276] [<c0096b14>] (kthread+0x84/0x90) from [<c000f3c8>] (kernel_thread_exit+0x0/0x8)
Allow the usbfs operation.
Bug: 19568950
Change-Id: Iffdc7bd93ebde8bb75c57a324b996e1775a0fd1e
STEPS TO REPRODUCE:
1. Connect the device to Mac.
2. Switch to AFT.
3. Now AFT on Mac will show the device contents.
4. Now drag and drop the file to device and observe.
EXPECTED RESULTS:
Should able to copy.
OBSERVED RESULTS:
Showing can not copy file and on clicking ok,
It shows device storage can not connect and close the AFT.
Addresses the following denial:
W kworker/u:11: type=1400 audit(0.0:729): avc: denied { use } for path="/storage/emulated/0/Download/song2.mp3" dev="fuse" ino=143 scontext=u:r:kernel:s0 tcontext=u:r:untrusted_app:s0:c512,c768 tclass=fd
12310 12530 E MtpRequestPacket: Malformed MTP request packet
ps -Z entry:
u:r:untrusted_app:s0:c512,c768 u0_a6 12310 203 android.process.media
Bug: 15835289
Change-Id: I47b653507f8d4089b31254c19f44706077e2e96a
Vold opens ASEC containsers on the sdcard, or OBB files from app's
home directories, both of which are supplied by vold. We need to
allow kernel threads to access those file descriptors.
Addresses the following denial:
loop0 : type=1400 audit(0.0:28): avc: denied { use } for path="/mnt/secure/asec/smdl1159865753.tmp.asec" dev="mmcblk1" ino=19 scontext=u:r:kernel:s0 tcontext=u:r:vold:s0 tclass=fd permissive=0
Bug: 19516891
Change-Id: I5a3607b48f5e0e504e4b3fcaec19152c3784f49d
Switch the kernel and init domains from unconfined_domain()
to permissive_or_unconfined() so that we can start collecting
and addressing denials in -userdebug/-eng builds.
Also begin to address denials for kernel and init seen after
making this switch.
I intentionally did not allow the following denials on hammerhead:
avc: denied { create } for pid=1 comm="init" name="memory.move_charge_at_immigrate" scontext=u:r:init:s0 tcontext=u:object_r:init_tmpfs:s0 tclass=file
avc: denied { open } for pid=1 comm="init" name="memory.move_charge_at_immigrate" dev="tmpfs" ino=6550 scontext=u:r:init:s0 tcontext=u:object_r:init_tmpfs:s0 tclass=file
These occur when init.rc does:
write /sys/fs/cgroup/memory/memory.move_charge_at_immigrate 1
because the prior command to mount the cgroup failed:
mount cgroup none /sys/fs/cgroup/memory memory
I think this is because that cgroup is not enabled in the
kernel configuration. If the cgroup mount succeeded,
then this would have been a write to a cgroup:file and
would have been allowed already.
Change-Id: I9d7e31bef6ea91435716aa4312c721fbeaeb69c0
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
When vold mounts an OBB on behalf of another application, the kernel
spins up the "loop0" thread to perform the mount operation. Grant
the kernel thread the ability to read app data files, so the mount
operation can succeed.
Steps to reproduce:
1) Run: runtest --path cts/tests/tests/os/src/android/os/storage/cts/StorageManagerTest.java
Expected:
1) All tests pass
Actual:
Test failure, with the following error message:
loop0 : type=1400 audit(0.0:46): avc: denied { read } for path="/data/data/com.android.cts.stub/files/test1.obb" dev="mmcblk0p16" ino=115465 scontext=u:r:kernel:s0 tcontext=u:object_r:app_data_file:s0 tclass=file permissive=0
Vold : Image mount failed (I/O error)
MountService: Couldn't mount OBB file: -1
StorageManager: Received message. path=/data/data/com.android.cts.stub/files/test1.obb, state=21
TestRunner: failed: testMountAndUnmountObbNormal(android.os.storage.cts.StorageManagerTest)
TestRunner: ----- begin exception -----
TestRunner: junit.framework.AssertionFailedError: OBB should be mounted
TestRunner: at junit.framework.Assert.fail(Assert.java:50)
TestRunner: at junit.framework.Assert.assertTrue(Assert.java:20)
TestRunner: at android.os.storage.cts.StorageManagerTest.mountObb(StorageManagerTest.java:235)
Bug: 17428116
Change-Id: Id1a39a809b6c3942ff7e08884b40e3e4eec73b6a
The kernel, when it creates a loop block device, starts a new
kernel thread "loop0" (drivers/block/loop.c). This kernel thread,
which performs writes on behalf of other processes, needs read/write
privileges to the sdcard. Allow it.
Steps to reproduce:
0) Get device with external, removable sdcard
1) Run: "adb install -s foo.apk"
Expected:
APK installs successfully.
Actual:
APK fails to install. Error message:
Vold E Failed to write superblock (I/O error)
loop0 W type=1400 audit(0.0:3123): avc: denied { read } for path="/mnt/secure/asec/smdl1645334795.tmp.asec" dev="mmcblk1p1" ino=528 scontext=u:r:kernel:s0 tcontext=u:object_r:vfat:s0 tclass=file permissive=0
PackageHelper E Failed to create secure container smdl1645334795.tmp
DefContainer E Failed to create container smdl1645334795.tmp
Bug: 17158723
(cherry picked from commit 4c6b13508d)
Change-Id: Iea727ac7958fc31d85a037ac79badbe9c85693bd
The kernel, when it creates a loop block device, starts a new
kernel thread "loop0" (drivers/block/loop.c). This kernel thread,
which performs writes on behalf of other processes, needs read/write
privileges to the sdcard. Allow it.
Steps to reproduce:
0) Get device with external, removable sdcard
1) Run: "adb install -s foo.apk"
Expected:
APK installs successfully.
Actual:
APK fails to install. Error message:
Vold E Failed to write superblock (I/O error)
loop0 W type=1400 audit(0.0:3123): avc: denied { read } for path="/mnt/secure/asec/smdl1645334795.tmp.asec" dev="mmcblk1p1" ino=528 scontext=u:r:kernel:s0 tcontext=u:object_r:vfat:s0 tclass=file permissive=0
PackageHelper E Failed to create secure container smdl1645334795.tmp
DefContainer E Failed to create container smdl1645334795.tmp
Bug: 17158723
Change-Id: I4aa86e372cc55348f6b8becfa17bd4da583925d4
Rename sdcard_internal/external types to fuse and vfat
respectively to make it clear that they are assigned to any
fuse or vfat filesystem by default (absent a context= mount option)
and do not necessarily represent the SDcard.
The sdcard_type attribute is still assigned to both types and
can still be used in allow rules to permit access to either the
internal or external SDcard.
Define type aliases for the old names to preserve compatibility
on policy reload and for device-specific policies that may not yet
be updated.
Change-Id: I8d91a8c4c1342b94e4f1bb62ca7ffd2ca4b06ba1
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
execute_no_trans controls whether a domain can execve a program
without switching to another domain. Exclude this permission from
unconfineddomain, add it back to init, init_shell, and recovery for
files in / and /system, and to kernel for files in / (to permit
execution of init prior to setcon). Prohibit it otherwise for the
kernel domain via neverallow. This ensures that if a kernel task
attempts to execute a kernel usermodehelper for which no domain transition
is defined, the exec will fail.
Change-Id: Ie7b2349923672dd4f5faf7c068a6e5994fd0e4e3
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Add neverallow rules to prohibit adding any transitions into
the kernel or init domains. Rewrite the domain self:process
rule to use a positive permission list and omit the transition
and dyntransition permissions from this list as well as other
permissions only checked when changing contexts. This should be
a no-op since these permissions are only checked when
changing contexts but avoids needing to exclude kernel or init
from the neverallow rules.
Change-Id: Id114b1085cec4b51684c7bd86bd2eaad8df3d6f8
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
These permissions are already allowed indirectly via unconfineddomain
and via domain, but ultimately we plan to remove them from those two
attributes. Explicitly allow the ones we expect to be required,
matching the complement of the auditallow rules in domain.te.
Change-Id: I43edca89d59c159b97d49932239f8952a848031c
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Narrow the relabelto rules to a more specific type set
for each domain.
Drop mount permissions from the kernel domain since mounting
occurs after switching to the init domain. This was likely
a residual of when all processes were left in the kernel domain
on a recovery boot due to the missing setcon statement in the
recovery init.rc.
Be consistent with unlabeled filesystems (i.e. filesystems
without any matching fs_use or genfs_contexts entry) so
that we can also unmount them.
Add comments to note the reason for various rules.
Change-Id: I269a1744ed7bf8c6be899494c5dc97847e5a994d
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Don't allow writes to /system from unconfined domains.
/system is always mounted read-only, and no process should
ever need to write there.
Allow recovery to write to /system. This is needed to apply OTA
images.
Change-Id: I11aa8bd0c3b7f53ebe83806a0547ab8d5f25f3c9
Writing to the /proc/self/attr files (encapsulated by the libselinux
set*con functions) enables a program to request a specific security
context for various operations instead of the policy-defined defaults.
The security context specified using these calls is checked by an
operation-specific permission, e.g. dyntransition for setcon,
transition for setexeccon, create for setfscreatecon or
setsockcreatecon, but the ability to request a context at all
is controlled by a process permission. Omit these permissions from
domain.te and only add them back where required so that only specific
domains can even request a context other than the default defined by
the policy.
Change-Id: I6a2fb1279318625a80f3ea8e3f0932bdbe6df676
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
We added these rules to the kernel domain when we removed them
from unconfined to ensure that we did not break anything. But
we have seen no uses of these rules and this matches our expectation
that any actual operations that require these permissions occurs
after switching to the init domain.
Change-Id: I6f3556a26b0f6f4e6effcb874bfc9498e7dfaa47
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Kernel userspace helpers may be spawned running in the kernel
SELinux domain. Those userspace helpers shouldn't be able to turn
SELinux off.
This change revisits the discussion in
https://android-review.googlesource.com/#/c/71184/
At the time, we were debating whether or not to have an allow rule,
or a dontaudit rule. Both have the same effect, as at the time we
switch to enforcing mode, the kernel is in permissive and the operation
will be allowed.
Change-Id: If335a5cf619125806c700780fcf91f8602083824
This was originally to limit the ability to relabel files to
particular types given the ability of all domains to relabelfrom
unlabeled files. Since the latter was removed by
Ied84f8b4b1a0896c1b9f7d783b7463ce09d4807b, this no longer serves
any purpose.
Change-Id: Ic41e94437188183f15ed8b3732c6cd5918da3397
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Only allow to domains as required and amend the existing
neverallow on block_device:blk_file to replace the
exemption for unconfineddomain with an explicit whitelist.
The neverallow does not check other device types as specific
ones may need to be writable by device-specific domains.
Change-Id: I0f2f1f565e886ae110a719a08aa3a1e7e9f23e8c
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Remove sys_ptrace and add a neverallow for it.
Remove sys_rawio and mknod, explicitly allow to kernel, init, and recovery,
and add a neverallow for them.
Remove sys_module. It can be added back where appropriate in device
policy if using a modular kernel. No neverallow since it is device
specific.
Change-Id: I1a7971db8d247fd53a8f9392de9e46250e91f89b
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Only allow to specific domains as required, and add a neverallow
to prevent allowing it to other domains not explicitly whitelisted.
sdcard_type is exempted from the neverallow since more domains
require the ability to mount it, including device-specific domains.
Change-Id: Ia6476d1c877f5ead250749fb12bff863be5e9f27
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Require all domain transitions or dyntransitions to be
explicitly specified in SELinux policy.
healthd: Remove healthd_exec / init_daemon_domain().
Healthd lives on the rootfs and has no unique file type.
It should be treated consistent with other similar domains.
Change-Id: Ief3c1167379cfb5383073fa33c9a95710a883b29
Now that we set /sys/fs/selinux/checkreqprot via init.rc,
restrict the ability to set it to only the kernel domain.
Change-Id: I975061fd0e69c158db9bdb23e6ba77948e3fead1
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
As per the discussion in:
https://android-review.googlesource.com/#/c/71184/
init sets the enforcing mode in its code prior to switching to
the init domain via a setcon command in the init.rc file. Hence,
the setenforce permission is checked while still running in the
kernel domain. Further, as init has no reason to ever set the
enforcing mode again, we do not need to allow setenforce to the
init domain and this prevents reverting to permissive
mode via an errant write by init later. We could technically
dontaudit the kernel setenforce access instead since the first
call to setenforce happens while still permissive (and thus we
never need to allow it in policy) but we allow it to more accurately
represent what is possible.
Change-Id: I70b5e6d8c99e0566145b9c8df863cc8a34019284
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
The build is broken. Reverting temporarily to fix breakage.
libsepol.check_assertion_helper: neverallow on line 4758 violated by allow init kernel:security { setenforce };
Error while expanding policy
make: *** [out/target/product/mako/obj/ETC/sepolicy_intermediates/sepolicy] Error 1
make: *** Waiting for unfinished jobs....
This reverts commit bf12e22514.
Change-Id: I78a05756d8ce3c7d06e1d9d27e6135f4b352bb85
As per the discussion in:
https://android-review.googlesource.com/#/c/71184/
init sets the enforcing mode in its code prior to switching to
the init domain via a setcon command in the init.rc file. Hence,
the setenforce permission is checked while still running in the
kernel domain. Further, as init has no reason to ever set the
enforcing mode again, we do not need to allow setenforce to the
init domain and this prevents reverting to permissive
mode via an errant write by init later. We could technically
dontaudit the kernel setenforce access instead since the first
call to setenforce happens while still permissive (and thus we
never need to allow it in policy) but we allow it to more accurately
represent what is possible.
Change-Id: I617876c479666a03167b8fce270c82a8d45c7cc6
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Start running in enforcing mode for kernel / init.
This should be mostly a no-op, as the kernel / init
is in the unconfined domain.
Change-Id: I8273d936c9a4eecb50b78ae93490a4dd52f59eb6
For additional context-
The denials related to init_tmpfs are of the form:
denied { read } for pid=12315 comm=""dboxed_process0"" path=2F6465762F6173686D656D2F64616C76696B2D68656170202864656C6574656429 dev=""tmpfs"" ino=9464 scontext=u:r:isolated_app:s0 tcontext=u:object_r:init_tmpfs:s0 tclass=file
(the path above is "/dev/ashmem/dalvik-heap (deleted)")
The denials related to executing things from the dalvik cache are of the form:
enied { execute } for pid=3565 comm=""dboxed_process0"" path=""/data/dalvik-cache/system@app@Chrome.apk@classes.dex"" dev=""mmcblk0p28"" ino=105983 scontext=u:r:isolated_app:s0 tcontext=u:object_r:dalvikcache_data_file:s0 tclass=file
The denials related to isolated_app and the init socket are:
denied { getattr } for pid=3824 comm=""Binder_2"" path=""socket:[14059]"" dev=""sockfs"" ino=14059 scontext=u:r:isolated_app:s0 tcontext=u:r:init:s0 tclass=unix_stream_socket
The getopt denials for the aforementioned socket are:
denied { getopt } for pid=3824 comm=""Binder_2"" path=""/dev/socket/dumpstate"" scontext=u:r:isolated_app:s0 tcontext=u:r:init:s0 tclass=unix_stream_socket
Change-Id: I3c57702e2af5a779a7618da9aa40930e7f12ee49
For unlabeled files, revert to DAC rules. This is for backwards
compatibility, as files created before SELinux was in place may
not be properly labeled.
Over time, the number of unlabeled files will decrease, and we can
(hopefully) remove this rule in the future.
To prevent inadvertantly introducing the "relabelto" permission, add
a neverallow domain, and add apps which have a legitimate need to
relabel to this domain.
Bug: 9777552
Change-Id: I71b0ff8abd4925432062007c45b5be85f6f70a88
