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. > 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.
