3 ms·

One article is about enforcing the exvlusive use of public APIs. The rest is about hardening the C/C++ code of AOSP. I dobnot see any "clamping down" here. What

One article is about enforcing the exvlusive use of public APIs. The rest is about hardening the C/C++ code of AOSP. I dobnot see any "clamping down" here. What am I missing?

pjmlp 8y ago
Using SE Linux and seccomp to close down entry points to the Linux kernel. Since this work only started on Android 7, it is clamping down the free reign that existed before.
- kllrnohj 8y ago
  Except they allow nearly everything for regular Android apps since libc lets you access nearly every syscall. Nothing was meaningfully "clamped down" there. You can't directly syscall some obsolete syscalls anymore, and you can't syscall random numbers, but nearly any actual real syscall is still accessible and nothing indicates that it won't be. As long as libc can do it so can you, since you & libc are in the same security domain. Or anything else that an NDK library can do in your process, you can go poke at that syscall, too. It'd almost always be stupid to do that instead of going through the wrappers, but you technically can
  - pjmlp 8y ago
    Android uses bionic.
    - kllrnohj 8y ago
      Yes, and..? Bionic is Android's libc. libc is just the name of the C standard library, not any particularly C standard library. You might be confused and thinking of glibc, which is a particular libc implementation.
      - pjmlp 8y ago
        And as such it is only required to expose ISO C functions.
- gmueckl 8y ago
  Looking at this list, the blocked syscalls do not seem to be too bad: https://github.com/aosp-mirror/platform_bionic/blob/master/libc/SECCOMP_BLACKLIST_APP.TXT https://github.com/aosp-mirror/platform_bionic/blob/master/l... This is mostly setgid/setuid, mount point and system clock related stuff. Except for syslog and chroit, I see no syscalls that you should be using in a user process anyway. So technically, this is clamping down Android, but it seems like a pretty reasonable restriction and far from a heavy handed approach.

One article is about enforcing the exvlusive use of public APIs. The rest is about hardening the C/C++ code of AOSP. I dobnot see any "clamping down" here. What am I missing?

pjmlp 8y ago

Using SE Linux and seccomp to close down entry points to the Linux kernel. Since this work only started on Android 7, it is clamping down the free reign that existed before.

kllrnohj 8y ago
Except they allow nearly everything for regular Android apps since libc lets you access nearly every syscall. Nothing was meaningfully "clamped down" there. You can't directly syscall some obsolete syscalls anymore, and you can't syscall random numbers, but nearly any actual real syscall is still accessible and nothing indicates that it won't be. As long as libc can do it so can you, since you & libc are in the same security domain. Or anything else that an NDK library can do in your process, you can go poke at that syscall, too. It'd almost always be stupid to do that instead of going through the wrappers, but you technically can
- pjmlp 8y ago
  Android uses bionic.
  - kllrnohj 8y ago
    Yes, and..? Bionic is Android's libc. libc is just the name of the C standard library, not any particularly C standard library. You might be confused and thinking of glibc, which is a particular libc implementation.
    - pjmlp 8y ago
      And as such it is only required to expose ISO C functions.
gmueckl 8y ago
Looking at this list, the blocked syscalls do not seem to be too bad: https://github.com/aosp-mirror/platform_bionic/blob/master/libc/SECCOMP_BLACKLIST_APP.TXT https://github.com/aosp-mirror/platform_bionic/blob/master/l... This is mostly setgid/setuid, mount point and system clock related stuff. Except for syslog and chroit, I see no syscalls that you should be using in a user process anyway. So technically, this is clamping down Android, but it seems like a pretty reasonable restriction and far from a heavy handed approach.