Thank you again. On Wed, Nov 2, 2016 at 9:25 AM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > As I said, you can prevent reading of the binary by all other processes > on the system, but not by the application itself. The domain in which > the application runs must be able to read the binary in order to execute > it as far as SELinux is concerned. And fundamentally, the running > application process always has read access to its executable (this may > change in the future with Intel Memory Protection Keys and execute-only > memory but that's not reality today). That makes sense. I will be running on an ARM architecture, so Intel Memory Protection Keys won't help :-) I haven't finished reading the documentation yet, so I don't know the correct syntax for specifying a policy. I do know that the SELinux approach is to disallow everything, except what is explicitly listed in the policy. Given that I am interested in starting small, and achieving this one goal of preventing read access to my application, would a reasonable custom policy look something like: Allow all file access to /bin to everybody Allow all file access to /usr to everybody Allow all device access to /dev to everybody etc... (for all of my directories in /... except /opt) Allow execute file access to /opt/local/myapp to everybody for /opt/local/myapp allow read access to /opt/local/myapp Yes, I know this exactly counter to the "dissallow everything, only allow what you need" mindset. My hope would be to achieve that mindset in the end, but as a starting point, and as an exercise in learning how to speak the policy language, would this be reasonable? > > The Android model is to put the init program (which loads the policy) > and the policy file into the initramfs, and the bootloader verifies the > signature of the boot image that contains the kernel and the initramfs. > That's as close we get to baking the policy into the kernel presently. > My approach was similar -- except that my whole (tiny) rootfs would be in the initramfs. And I guess I would need to ensure that my policy did not explicitly allow the policy to be changed. Thanks again for your help. This is starting to make sense. --wpd _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
