On 11/02/2016 11:10 AM, Patrick Doyle wrote: > On Wed, Nov 2, 2016 at 10:08 AM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: >> No. For example, if all processes can access all /dev nodes, then they >> can perform raw reads/writes to the block devices and thereby circumvent >> any file-based access controls entirely. If all processes can write to >> e.g. /lib, then they can replace the dynamic linker and any shared >> libraries used by your application and get it to execute their code in >> order to dump its memory. If they can all execute your application, >> then they can run its binary in their own memory and then dump its >> contents. > I didn't realize that saying "Allow all access" would circumvent the > normal Linux based file permissions. I assumed that SELinux was > layered on top of those permissions. I guess I have more to learn. No, my comments were with respect to SELinux, not DAC. DAC is still in effect and SELinux does not override DAC denials. But the point remains: if you are trying to protect against an errant root process, then the policy you described won't provide any real protection. > > >> Please, see my original email and answer the questions there >> (which you mostly ignored) to see whether this is even a worthwhile >> exercise, and then, if so, follow the guidance for using sound DAC >> ownership and modes first, then investigate SELinux to address residual >> gaps. > ok. That is what I have been attempting to do... one residual gap I > see with that is that a root user can make a copy of my application. > I would like to prevent that. > >>> Is anything besides your application even running on the device? > yes > >>> Are there other services/applications that run on the device too? > yes > >>> When you say "gain access to my device", what kind of access did you have in mind? > > I am assuming that somebody has managed to gain root access to my > device, possibly via a serial port, or possibly via a remote exploit > of one of the other services running on the device. (S)He will > certainly have physical access to the device, and therefore my kernel > & rootfs will be encrypted, (and the key would be protected by the > secure boot facilities of the SoC). But if (s)he gains root access to > the file system, I don't want him/her to be able to be able to copy my > application code off the device. > >> >> If you want a simple, small SELinux policy to start from, I would again >> recommend the Android SELinux policy. >> > Very well. I will start there and save the rest of my questions until > after I have learned more. > > Thanks again for your tips and advice. > > --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.
