android 4.3安全更新

Enterprise and Security

看完了泪流满面啊。。。OS就是黑洞，啥都做了！一会详细分析！

我先下载体验：

https://developers.google.com/android/nexus/images

 Android 4.3安全增强

• Android sandbox reinforced with SELinux. This release strengthens the Android sandbox using the SELinux mandatory access control system (MAC) in the Linux kernel. SELinux reinforcement is invisible to users and developers, and adds robustness to the existing Android security model while maintaining compatibility with existing applications. To ensure continued compatibility this release allows the use of SELinux in a permissive mode. This mode logs any policy violations, but will not break applications or affect system behavior.

目前4.3的SE还处在生长期，开启的是permissive mode（就是“我就是看看”模式），不采取实际行动。先让OEM练练手。

SELinux有三种模式：Enforcing, Permissive and Disable.

Enforcing模式就是应用SELinux所设定的Policy, 所有违反Policy的规则(Rules)都会被SELinux拒绝
Permissive和Enforcing的区别就在于它还是会遵循SELinux的Policy,但是对于违反规则的操作只会予以记录而并不会拒绝操作

Disable 顾名思义就是完全禁用SELinux

 

In this release, Android includes SELinux in permissive mode and a corresponding security policy that works by default across theAndroid Open Source Project. In permissive mode, no actions are prevented. Instead, all potential violations are logged by the kernel todmesg. This allows Android and Android device manufacturers to gather information about errors so they may refine their software and SELinux policies before enforcing them.

 

• No setuid/setgid programs. Added support for filesystem capabilities to Android system files and removed all setuid/setguid programs. This reduces root attack surface and the likelihood of potential security vulnerabilities.
• ADB Authentication. Since Android 4.2.2, connections to ADB are authenticated with an RSA keypair. This prevents unauthorized use of ADB where the attacker has physical access to a device.
• Restrict Setuid from Android Apps. The /system partition is now mounted nosuid for zygote-spawned processes, preventing Android applications from executing setuid programs. This reduces root attack surface and the likelihood of potential security vulnerabilities.
• Capability bounding. Android zygote and ADB now use prctl(PR_CAPBSET_DROP) to drop unnecessary capabilities prior to executing applications. This prevents Android applications and applications launched from the shell from acquiring privileged capabilities.
• AndroidKeyStore Provider. Android now has a keystore provider that allows applications to create exclusive use keys. This provides applications with an API to create or store private keys that cannot be used by other applications.
• KeyChain isBoundKeyAlgorithm. Keychain API now provides a method (isBoundKeyType) that allows applications to confirm that system-wide keys are bound to a hardware root of trust for the device. This provides a place to create or store private keys that cannot be exported off the device, even in the event of a root compromise.
• NO_NEW_PRIVS. Android zygote now uses prctl(PR_SET_NO_NEW_PRIVS) to block addition of new privileges prior to execution application code. This prevents Android applications from performing operations which can elevate privileges via execve. (This requires Linux kernel version 3.5 or greater).
• FORTIFY_SOURCE enhancements. Enabled FORTIFY_SOURCE on Android x86 and MIPS and fortified strchr(), strrchr(), strlen(), and umask() calls. This can detect potential memory corruption vulnerabilities or unterminated string constants.
• Relocation protections. Enabled read only relocations (relro) for statically linked executables and removed all text relocations in Android code. This provides defense in depth against potential memory corruption vulnerabilities.
• Improved EntropyMixer. EntropyMixer now writes entropy at shutdown / reboot, in addition to periodic mixing. This allows retention of all entropy generated while devices are powered on, and is especially useful for devices that are rebooted immediately after provisioning.
• Security Fixes. Android 4.3 also includes fixes for Android-specific vulnerabilities. Information about these vulnerabilities has been provided to Open Handset Alliance members and fixes are available in Android Open Source Project. To improve security, some devices with earlier versions of Android may also include these fixes.

---

Wi-Fi configuration for WPA2-Enterprise networks

Apps can now configure the Wi-Fi credentials they need for connections toWPA2 enterprise access points. Developers can use new APIs to configure Extensible Authentication Protocol (EAP) and Encapsulated EAP (Phase 2) credentials for authentication methods used in the enterprise. Apps with permission to access and change Wi-Fi can configure authentication credentials for a variety of EAP and Phase 2 authentication methods.

Android sandbox reinforced with SELinux

Android now uses SELinux, a mandatory access control (MAC) system in the Linux kernel to augment the UID based application sandbox. This protects the operating system against potential security vulnerabilities.

KeyChain enhancements

The KeyChain API now provides a method that allows applications to confirm that system-wide keys are bound to ahardware root of trust for the device. This provides a place to create or store private keys thatcannot be exported off the device, even in the event of a root or kernel compromise.

Android Keystore Provider

Android 4.3 introduces a keystore provider and APIs that allow applications to create exclusive-use keys. Using the APIs, apps can create or store private keys thatcannot be seen or used by other apps, and can be added to the keystore without any user interaction.

The keystore provider provides the same security benefits that the KeyChain API provides for system-wide credentials, such as binding credentials to a device. Private keys in the keystore cannot be exported off the device.

Restrict Setuid from Android Apps

The /system partition is now mounted nosuid for zygote-spawned processes, preventing Android applications from executingsetuid programs. This reduces root attack surface and likelihood of potential security vulnerabilities.

 

Support for Restricted Profiles

---

 

A tablet owner can set up one or more restricted profiles in Settings and manage them independently.

Your app can offer restrictions to let owners manage your app content when it's running in a profile.

Android 4.3 extends the multiuser feature for tablets with restricted profiles, a new way to manage users and their capabilities on a single device. With restricted profiles, tablet owners can quickly set upseparate environments for each user, with the ability to manage finer-grained restrictions in the apps that are available in those environments. Restricted profiles are ideal for friends and family, guest users, kiosks, point-of-sale devices, and more.

Each restricted profile offers an isolated and secure space with its own local storage, home screens, widgets, and settings. Unlike with users, profiles are created from the tablet owner’s environment, based on the owner’s installed apps and system accounts. The owner controls which installed apps are enabled in the new profile, and access to the owner’s accounts is disabled by default.

Apps that need to access the owner’s accounts — for sign-in, preferences, or other uses — can opt-in by declaring a manifest attribute, and the owner can review and manage those apps from the profile configuration settings.

For developers, restricted profiles offer a new way to deliver more value and control to your users. You can implementapp restrictions— content or capabilities controls that are supported by your app —and advertise them to tablet owners in the profile configuration settings.

You can add app restrictions directly to the profile configuration settings using predefined boolean, select, and multi-select types. If you want more flexibility, you can even launch your own UI from profile configuration settings to offer any type of restriction you want.

When your app runs in a profile, it can check for any restrictions configured by the owner and enforce them appropriately. For example, a media app might offer a restriction to let the owner set a maturity level for the profile. At run time, the app could check for the maturity setting and then manage content according to the preferred maturity level.

If your app is not designed for use in restricted profiles, you can opt out altogether, so that your app can't be enabled in any restricted profile.