When the flag is on, insmod will bypass vermagic and symbol version
checking in the kernel. This is to make it possible to update kernel
without recompiling kernel modules.
BUG=28803994
Change-Id: Ib4be6999ef52baefd4210ee0d242360e43318907
Arguments of commands are expanded based on properties if they contain
${property.name}, however this is not currently done for arguments of
services.
This patch makes it that arguments of services are expanded each time
that the service starts at the point immediately before execve().
Change-Id: Iba581a8377e25a6478d4d2ec2e8b29e181d8640c
am: fb9c42648f
* commit 'fb9c42648f05f0c8490761be201188d3ff64fde1':
use process groups for processes started by init
Change-Id: Id59985d52550af2c8bce637817aed12103ade802
Put every service into a process group, kill the process group
and all child processes created within the group when killing the
service. Removed libutil dependency in libprocessgroup.
Bug: 25355957
Change-Id: Ieed60ec41579f638ab9b1e66a7e6330ed578ab05
Signed-off-by: Collin Mulliner <collinrm@squareup.com>
Since commit: 24a3cbfa73
ueventd is attempting to relabel devices on calls to
make_device() when the device already exists. However, it
should only be called if the contexts for relabelfrom and
relabelto are different.
When this condition occurs, one will see denials like this:
[ 14.409448] type=1400 audit(978307239.225:26): avc: denied { relabelfrom } for pid=1572 comm="ueventd" name="ttyS0" dev="tmpfs" ino=9613 scontext=u:r:ueventd:s0 tcontext=u:object_r:hci_attach_dev:s0 tclass=chr_file permissive=1
[ 14.428107] type=1400 audit(978307239.225:27): avc: denied { relabelto } for pid=1572 comm="ueventd" name="ttyS0" dev="tmpfs" ino=9613 scontext=u:r:ueventd:s0 tcontext=u:object_r:hci_attach_dev:s0 tclass=chr_file permissive=1
Bug: 29106809
Change-Id: I2105b169206f0b26420f3c4b0ba5c49aeb98da92
Signed-off-by: William Roberts <william.c.roberts@intel.com>
am: 9582b1a3f1
* commit '9582b1a3f16e3bf492af38ec166eb6d23f65cedf':
init: support matching sysfs class paths in ueventd.rc
Change-Id: Id1d9a1db1d677164347f5d3092b4d3c33292dd30
am: 0da9f42f2c
* commit '0da9f42f2c2ec6985018ad45603b32532d096a60':
init: support matching sysfs class paths in ueventd.rc
Change-Id: Ifc85ba3205a5207a4285da94b483164490dbde4d
Currently, ueventd.rc files only support /sys/devices/... paths
and don't support symlinked paths, specifically /sys/class/...
Supporting the class paths is necessary to have non-hardware
dependent paths. Some subsystems like IIO use /sys/bus/iio/, so
support that as well.
Change-Id: I29f3bf67b41664d1d75ac1820c46e13afe336d56
Signed-off-by: Rob Herring <robh@kernel.org>
fixup_sys_perms does the same matching as the function perm_path_matches
other than the leading '/sys'. Adjust the path and use the common
matching function. Replace the fixed length C strings with std::string.
Change-Id: Ic09d91aa4ac1f1096018617537d782b82ee9ef63
Signed-off-by: Rob Herring <robh@kernel.org>
If we fail to set a crypto policy on a system-DE directory, this is a
serious and unrecoverable condition; the only way forward is to erase
the entire device. In a future commit we will also allow users the
option of booting again.
Bug: 28318405
Change-Id: Iff1e52c5bbee1beed29dc4b609d24bfeb7d138da
Switch insmod from using init_module to finit_module. From
"man finit_module":
The finit_module() system call is like init_module(), but reads the
module to be loaded from the file descriptor fd. It is useful when the
authenticity of a kernel module can be determined from its location in
the file system; in cases where that is possible, the overhead of
using cryptographically signed modules to determine the authenticity
of a module can be avoided.
finit_module is preferred over init_module because it allows LSMs, such
as SELinux, to perform a permission check on kernel module loads based on
the file from which the module is loaded. This functionality is not yet
implemented in the Linux kernel, but is on the SEAndroid TODO list.
See https://bitbucket.org/seandroid/wiki/wiki/ToDo
Bug: 27824855
(cherry picked from commit 124a9c97e9)
Change-Id: I5e87de1a7b8c3d8849bf757c71b08e81c378b021
There is a race in ueventd's coldboot procedure that permits creation
of device block nodes before platform devices are registered. This happens
when the kernel sends events for adding block devices during ueventd's
coldboot /sys walk.
In this case the device node links used to compute the SELinux context
are not known and the node is created under the generic context:
u:object_r:block_device:s0.
A second add event for block device nodes is triggered after the platform
devices are handled by ueventd and the SELinux context is correctly computed
but the mknod call fails because the node already exists. This patch handles
this error case and updates the node's security context.
The race is introduced by the uevent sent from the sdcard device probe
function. The issue appears when this uevent is triggered during ueventd's
coldboot procedure but before the /sys/devices recursive walk reached the
corresponding sdcard platform device path.
The backtrace looks something like:
1. ueventd_main()
2. device_init()
3. coldboot("/sys/devices");
4. do_coldboot()
5. handle_device_fd()
6. handle_device_event()
6.1 handle_block_device_event()
6.2 handle_platform_device_event()
Because handle_device_fd() reads all events from the netlink socket it may
handle the add events for the sdcard partition nodes send occasionally by the
kernel during coldboot /sys walk procedure.
If handle_device_event() continues with handle_block_device_event()
before handle_platform_device_event() registers the sdcard platform device then
handle_block_device_event() will create device nodes without knowing all block
device symlinks (get_block_device_symlinks()):
1. handle_device(path=/dev/block/mmcblk0p3, links = NULL)
2. make_device(path=/dev/block/mmcblk0p3, links = NULL)
3. selabel_lookup_best_match(path=/dev/block/mmcblk0p3, links = NULL)
returns the default context (u:object_r:block_device:s0) for
/dev/block/mmcblk0p3 instead of more specific context like:
u:object_r:boot_block_device:s0
4. setfscreatecon(u:object_r:block_device:s0)
5. mknod(/dev/block/mmcblk0p3)
So the node is create with the wrong context. Afterwards the coldboot /sys walk
continues and make_device() will be called with correct path and links.
But even if the secontext is computed correctly this time it will not be
applied to the device node because mknod() fails.
I see this issue randomly appearing (one time in 10 reboots) on a Minnoboard
Turbot with external sdcard as the boot device.
BUG=28388946
Signed-off-by: Mihai Serban <mihai.serban@intel.com>
(cherry picked from commit 24a3cbfa73)
Change-Id: I2d217f1c8d48553eb4a37457dbf27fff54051cf9
There is a race in ueventd's coldboot procedure that permits creation
of device block nodes before platform devices are registered. This happens
when the kernel sends events for adding block devices during ueventd's
coldboot /sys walk.
In this case the device node links used to compute the SELinux context
are not known and the node is created under the generic context:
u:object_r:block_device:s0.
A second add event for block device nodes is triggered after the platform
devices are handled by ueventd and the SELinux context is correctly computed
but the mknod call fails because the node already exists. This patch handles
this error case and updates the node's security context.
The race is introduced by the uevent sent from the sdcard device probe
function. The issue appears when this uevent is triggered during ueventd's
coldboot procedure but before the /sys/devices recursive walk reached the
corresponding sdcard platform device path.
The backtrace looks something like:
1. ueventd_main()
2. device_init()
3. coldboot("/sys/devices");
4. do_coldboot()
5. handle_device_fd()
6. handle_device_event()
6.1 handle_block_device_event()
6.2 handle_platform_device_event()
Because handle_device_fd() reads all events from the netlink socket it may
handle the add events for the sdcard partition nodes send occasionally by the
kernel during coldboot /sys walk procedure.
If handle_device_event() continues with handle_block_device_event()
before handle_platform_device_event() registers the sdcard platform device then
handle_block_device_event() will create device nodes without knowing all block
device symlinks (get_block_device_symlinks()):
1. handle_device(path=/dev/block/mmcblk0p3, links = NULL)
2. make_device(path=/dev/block/mmcblk0p3, links = NULL)
3. selabel_lookup_best_match(path=/dev/block/mmcblk0p3, links = NULL)
returns the default context (u:object_r:block_device:s0) for
/dev/block/mmcblk0p3 instead of more specific context like:
u:object_r:boot_block_device:s0
4. setfscreatecon(u:object_r:block_device:s0)
5. mknod(/dev/block/mmcblk0p3)
So the node is create with the wrong context. Afterwards the coldboot /sys walk
continues and make_device() will be called with correct path and links.
But even if the secontext is computed correctly this time it will not be
applied to the device node because mknod() fails.
I see this issue randomly appearing (one time in 10 reboots) on a Minnoboard
Turbot with external sdcard as the boot device.
BUG=28388946
Change-Id: I96e239af29d82b753e5d349b3ecefaad09edee87
Signed-off-by: Mihai Serban <mihai.serban@intel.com>
