Solve one more issue where privilege is required to open a file and
we do not want to grant such to the service. This is the service side
of the picture, android_get_control_file() in libcutils is the client.
The file's descriptor is placed into the environment as
"ANDROID_FILE_<path>". For socket and files where non-alpha and
non-numeric characters in the <name/path> are replaced with _. There
was an accompanying change in android_get_control_socket() to match
in commit 'libcutils: add android_get_control_socket() test'
Add a gTest unit test for this that tests create_file and
android_get_control_file().
Test: gTest init_tests --gtest_filter=util.create_file
Bug: 32450474
Change-Id: I96eb970c707db6d51a9885873329ba1cb1f23140
Ambient capabilities are inherited in a straightforward way across
execve(2):
"
If you are nonroot but you have a capability, you can add it to pA.
If you do so, your children get that capability in pA, pP, and pE.
For example, you can set pA = CAP_NET_BIND_SERVICE, and your
children can automatically bind low-numbered ports.
"
This will allow us to get rid of the special meaning for AID_NET_ADMIN
and AID_NET_RAW, and if desired, to reduce the use of file capabilities
(which grant capabilities to any process that can execute the file). An
additional benefit of the latter is that a single .rc file can specify
all properties for a service, without having to rely on a separate file
for file capabilities.
Ambient capabilities are supported starting with kernel 4.3 and have
been backported to all Android common kernels back to 3.10.
I chose to not use Minijail here (though I'm still using libcap) for
two reasons:
1-The Minijail code is designed to work in situations where the process
is holding any set of capabilities, so it's more complex. The situation
when forking from init allows for simpler code.
2-The way Minijail is structured right now, we would not be able to
make the required SELinux calls between UID/GID dropping and other priv
dropping code. In the future, it will make sense to add some sort of
"hook" to Minijail so that it can be used in situations where we want
to do other operations between some of the privilege-dropping
operations carried out by Minijail.
Bug: 32438163
Test: Use sample service.
Change-Id: I3226cc95769d1beacbae619cb6c6e6a5425890fb
bootcharts currently only show root's processes, which isn't very
useful. To investigate and track boot duration issues, we need a way for
init to see all the pids. Add init to GID 3009 (aka AID_READPROC)
Ensure that init's children don't inherit this GID by always clearing
supplementary group IDs on fork.
Bug: 32506197
Test: Device boots and /proc/1/status says init is in gid 3009
Test: zygote starts and the Group: line in /proc/ZYGOTEPID/status is empty
Change-Id: Iba90717aaa591f1d6030a379a272aee003600c0a
Not-Tested: bootchart actually works. Speculative fix.
Services implementing HIDL HALs must be named the same as the HIDL
package, e.g. android.hardware.nfc@1.0. Allow init to accept names
containing '.' and '@'.
Also combined logic for legal property names and legal service names.
Bug: 31458381
Bug: 32109611
Test: Tested creating service nfc@1.0-service which creates property
'init.svc.nfc@1.0-service' with and without this change. This service
successfully started only with this change.
Change-Id: Ie7a4310742bc03498d774d37b3b5fafa7c6068cc
Signed-off-by: Iliyan Malchev <malchev@google.com>
For each service ${service} described in a .rc file, init creates the
property init.svc.${service}. This implies that service-name lengths
are bound by the maximum size of a property. This patch accounts for
the "init.svc." prefix and the maximum property-name length when
validating a service name.
Test: pass
Change-Id: I32dffa37363b41a8211f7644600b81973d30a3b2
Signed-off-by: Iliyan Malchev <malchev@google.com>
These events are _somewhat_ normal, in that not all devices have all
partitions, but not logging anything makes it unnecessarily hard for
folks to debug simple failures.
Bug: http://b/31186390
Test: booted, checked dmesg
Change-Id: I403377c585ea35cfe73b0bed9443b75e3a84dc8d
This will make it possible to start some key services before mounting
data partition
Bug: 30118894
Change-Id: Ia9f8cc035de6cc0df9a61605864915efa0266d7f
(cherry picked from commit abfbec342f)
This will make it possible to start some key services before mounting
data partition
(cherry picked from commit abfbec342f)
Bug: 30118894
Change-Id: Ia9f8cc035de6cc0df9a61605864915efa0266d7f
Create /dev/random and /dev/urandom in the first stage, so that when we
reexec, arc4random is available for libc initialization.
Bug: http://b/29622562
Change-Id: I5b2071539a17eec609faac91dc28b08eba5ff89b
Right now these two partitions are mounted in the fs stage of the init
process. As a result, many vendor/ODM files needed earlier in the boot
process (e.g., init.<hardware>.rc, fstab.<hardware>.rc,
uevent.<hardware>.rc, SELinux policy files etc) can only live on the root
partition.
To prevent vendors/ODMs from polluting the root partition, this patch makes
it possible to mount the vendor and ODM partitions in the first stage of the
init process. The fstab info of both partitions to be mounted early is
composed from new kernel cmdline arguments android.early.prefix and
android.early.fstab.
For example, with:
android.early.prefix=/sys/devices/1010000.msdc0/mmc_host/mmc0/mmc0:0001/block/mmcblk0/
android.early.fstab=mmcblk0p10+/odm+ext4+ro+verify\nmmcblk0p09+/vendor+ext4+ro+verify
the final fstab string will be:
/sys/devices/1010000.msdc0/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p10 /odm ext4 ro verify
/sys/devices/1010000.msdc0/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p09 /vendor ext4 ro verify
The android.early.prefix is optional. When it is missing, the final fstab
string will be directly converted from android.early.fstab.
This patch also makes sure that the early mounted partitions are dm-verity
enabled so that they are trust worthy to store system files.
BUG=27805372
Change-Id: I3cf32482a5ec65445ba3aedab2164c7ba8f12694
killProcessGroup actually works on cgroups. Kill the POSIX process
group ourselves.
Bug: http://b/29751426
Change-Id: I1a2808488510f4262811b6407bcd0948ad23bc60
* Use const reference type for parameters to avoid unnecessary copy.
* Suppress warning of not using faster overloaded string find function.
Bug: 30407689
Bug: 30411878
Change-Id: I6cfdbbd50cf5e8f3db6e5263076d3a17a9a791ee
Test: build with WITH_TIDY=1
Merged-In: Ie79dbe21899867bc62031f8618bb1322b8071525
Often a bugreport is accidentally triggered by the combo keys, but there
is nothing in the bugreport to confirm that action because init's
klog level is KLOG_NOTICE_LEVEL.
This change change keychord's INFO messages to NOTICE, and also logs the
case where a service was not launched because ADB was disabled.
BUG: 30440213
BUG: 30345559
Change-Id: I6ccadef1621cb41dcd15e7c1660366f0e147dc7a
Remove the /dev/__kmsg__ workarounds (which can then be removed
from sepolicy), and fix confusion in the translation between
android-base logging and kernel logging priorities (in particular,
where 'notice' comes in the hierarchy).
Bug: http://b/30317429
Change-Id: I6eaf9919904b6b55bc402c20bf1a4ae269014bc7
Test: adb shell dmesg | grep init
On FBE devices, the filenames inside credential-encrypted directories
are mangled until the key is installed. This means the initial
restorecon at boot needs to skip these directories until the keys
are installed.
This CL changes the implementation of the "restorecon_recursive"
built-in command to use the new SKIPCE flag to avoid labeling files
in CE directories. vold will request a restorecon when the keys
are actually installed.
Bug: 30126557
Change-Id: I320584574a4d712c493b5bbd8a79b56c0c04aa58
Right now we set sys.usb.controller property in init.$platform.usb.rc
to enable ConfigFS gadgets.
Let system detect and set UDC driver name from /sys/class/udc instead.
Change-Id: I99ad49d24dc53b543c5573e209bf00d6c2d91dd4
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
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().
Bug: 28788401
Change-Id: Iba581a8377e25a6478d4d2ec2e8b29e181d8640c
This CL extracts code from Service::Start into four helper functions,
bringing Service::Start down to 134 lines vs 212 lines originally. This
makes the method a lot easier to follow. There is no change in behaviour.
Also, make error messages consistent (start with lowercase) and
format Service::Start to fit in 100 cols.
Bug: 30035168
Change-Id: If979976fba4d339a336d030f802ca9f169fd012c
I'll come back and remove klog_init when I've removed other calls to it.
Change-Id: Iad7fd26d853b4ddc54e9abd44516b6f138cbbfcb
Test: booted N9, looked at "adb shell dmesg" output.
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
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: 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>
The old way (using triggers) starts defaultcrypto twice because
queue_property_triggers_action retriggers the action.
Bug: 27452459
Change-Id: I48c844836f551673d0dbfed6c33bd8ee1e035f40
Vineela Tummalapalli