Add SE Android support for init and ueventd.
init:
- Load policy at boot.
- Set the security context for service daemons and their sockets.
- New built-in commands: setcon, setenforce, restorecon, setsebool.
- New option for services: seclabel.
ueventd:
- Set the security context for device directories and nodes.
Change-Id: I98ed752cde503c94d99dfa5b5a47e3c33db16aac
Creating a root owned /data/local.prop is one of the most common
ways to root an Android device. /data/local.prop is only intended
to assist developers on debuggable devices, and is never
intended to be used on production devices.
Change-Id: Ifcfa21c2ee9914b0b54445218b4cf0fea0a98e9c
If we process the import directive inline, then the ordering of the
commands for the "on xxx" sections would be a little unexpected. The
init.rc files do not really have an implied order as to which section
appears and gets processed first. The init code itself provides that
ordering explicitly. For the user, the expectation is that if both the
current file and the imported file define a section (e.g. "on init"),
then the commands in the current file will be executed first, and then
the ones from the imported file(s).
The current implementation did not do that. It processed the import
directive inline, and thus the imported (i.e. dependent) files would
appear first in the command lists for the sections. This created
unintended side effects and the solution would have been to try and
put the import lines somewhere in the middle of the init file. This
would be difficult to notice and hard to extract the dependencies.
To solve this, we add the imports to a list for each file being parsed
and process the list after finishing parsing the file. This provides
predictable order for imports and provides a logical flow from the
user perspective: the currently parsed file gets to run its commands
before the files being imported.
Change-Id: I06dc35ff286314060e16b18923683cd2787269de
Signed-off-by: Dima Zavin <dima@android.com>
Also, clean up how we initialize the ro.xx properties and process
the kernel command line.
Change-Id: Iedda6c90e31340a189171a44b2767480403354f7
Signed-off-by: Dima Zavin <dima@android.com>
This removes the hardcoding of the file import in init and instead
allows the init.rc file to fully control what is loaded.
Change-Id: I933e5bbab57f1e8705a370d660f92c6508da94d2
Signed-off-by: Dima Zavin <dima@android.com>
Adds new property syntax in init files during init file filename
expansion during the import command:
${prop.name}
So, one can do: import /init.${ro.hardware}.usb.rc
Should convert other usages of property names to use the new function.
Change-Id: I9205d7d7a2da620bc8e6b89ac0eb554fad53ded3
Signed-off-by: Dima Zavin <dima@android.com>
The property service is still started later, but the property area
and the initial boot properties are initialized before the init.rc
file is processed. This allows init.rc files to have access to boot
properties during parsing.
Change-Id: Iae9ed1093c821831a864b39ae6bc697e62b94757
Signed-off-by: Dima Zavin <dima@android.com>
If we process the import directive inline, then the ordering of the
commands for the "on xxx" sections would be a little unexpected. The
init.rc files do not really have an implied order as to which section
appears and gets processed first. The init code itself provides that
ordering explicitly. For the user, the expectation is that if both the
current file and the imported file define a section (e.g. "on init"),
then the commands in the current file will be executed first, and then
the ones from the imported file(s).
The current implementation did not do that. It processed the import
directive inline, and thus the imported (i.e. dependent) files would
appear first in the command lists for the sections. This created
unintended side effects and the solution would have been to try and
put the import lines somewhere in the middle of the init file. This
would be difficult to notice and hard to extract the dependencies.
To solve this, we add the imports to a list for each file being parsed
and process the list after finishing parsing the file. This provides
predictable order for imports and provides a logical flow from the
user perspective: the currently parsed file gets to run its commands
before the files being imported.
Change-Id: I06dc35ff286314060e16b18923683cd2787269de
Signed-off-by: Dima Zavin <dima@android.com>
Also, clean up how we initialize the ro.xx properties and process
the kernel command line.
Change-Id: Iedda6c90e31340a189171a44b2767480403354f7
Signed-off-by: Dima Zavin <dima@android.com>
This removes the hardcoding of the file import in init and instead
allows the init.rc file to fully control what is loaded.
Change-Id: I933e5bbab57f1e8705a370d660f92c6508da94d2
Signed-off-by: Dima Zavin <dima@android.com>
Adds new property syntax in init files during init file filename
expansion during the import command:
${prop.name}
So, one can do: import /init.${ro.hardware}.usb.rc
Should convert other usages of property names to use the new function.
Change-Id: I9205d7d7a2da620bc8e6b89ac0eb554fad53ded3
Signed-off-by: Dima Zavin <dima@android.com>
The property service is still started later, but the property area
and the initial boot properties are initialized before the init.rc
file is processed. This allows init.rc files to have access to boot
properties during parsing.
Change-Id: Iae9ed1093c821831a864b39ae6bc697e62b94757
Signed-off-by: Dima Zavin <dima@android.com>
The class_reset command used to reset services that had been set to
"disabled" in the init.rc file to a non-disabled state. Now, if the
service was originally set to "disabled", have the reset command set
it back to disabled. Otherwise, set it to the "reset" state as it
currently does.
Change-Id: I0c10582e46a8e443d4748d9d893ae762b19b653a
x86 emulator passes hardware name through the androidboot.hardware kernel cmd option, and
ueventd must pick up on it to locate proper ueventd.rc file for that hardware.
Change-Id: Id61c5b67fe6275a15c7aa62556e0b89eda7968f8
Introduces a 'charger' section that is processed when androidboot.mode
supplied on the kernel commandline is "charger".
In this mode, sections such as fs, post-fs, etc are skipped. Only the
'early-init' and 'init' sections of the init rc files are processed before
processing the 'charger' section.
Change-Id: If9eb6334de18f04cbcf2aab784578e2993615242
Signed-off-by: Dima Zavin <dima@android.com>
VPN no longer uses system properties to keep network parameters.
Besides, profiles are now stored and encrypted by keystore.
Change-Id: I7575f04f350b7d8d5ba7008eb874a72180d057e8
This allows us to change permissions and ownerships of directories
in init scripts without adding additional commands.
Change-Id: I1815d6015953035251b98f28c0f3efd3c7f25f80
For example, the following trigger will fire when the sys.foo property
is set to any value:
on property:sys.foo=*
write /data/foo hello
It is also possible to refer to the property within the trigger actions:
on property:sys.foo=*
write /data/foo $sys.foo
Change-Id: If78d20a532f77e17aa5703d53be581ad6736cbcf
Signed-off-by: Mike Lockwood <lockwood@android.com>
The write command will write a property value if the value starts with a "$'
For example:
write /sys/class/android_usb/iSerial $ro.serialno
Use double leading '$' if you need to write a string that starts with '$':
write /data/foo $$hello
to write "$hello" to /data/foo
Change-Id: I55431ac7715a5347bb95c3a15aee97c575444dde
Jean-Baptiste Queru
Stephen Smalley
Nick Kralevich
Dima Zavin
Jeff Brown
Ken Sumrall
Vladimir Chtchetkine
Benoit Goby
Conley Owens
Chia-chi Yeh
Mike Lockwood
Vernon Tang