Our company is developing an AOSP-based platform for our customer. Some of our vendor services are using HWBinder for IPC which is using SELinux to restrict service discovery and access. The problem is that our customer insists that SELinux restriction is not enough and we need to provide a DAC-based restriction as well.

Our customer is basing this requirement on a security audit that was conducted on an earlier version of the platform. This security audit, however, didn't evaluate HWBinder IPC, but a socket-based IPC that was used in older services. The issue that was highlighted during this audit is that Unix sockets had 0666 access and a recommendation was to change it to 0660 and use Unix groups to allow only specific services to access the socket.

For some reason our customer is now requiring to apply the same (or similar) approach to HWBinder IPC which, however, doesn't have anything to attach these permissions to.

Unfortunately so far I couldn't get a straight answer regarding their threat model, so my question is: Does it even make sense to require DAC + SELinux and if so, what threat model should I be considering to properly implement this restriction?

Also, any ideas regarding how I can get our customer an additional layer of security without changing the IPC method would be greatly appreciated.

1 Answer 1


World-writable files are pretty much considered bad in all but very specific scenarios. If there is no legitimate reason to have a file wide-open for the world to read/write to, it's best practice to lock it down. Nearly all security audits will mark a failure for world-writable files... period. And remember, in the UNIX world, everything is a "file".

Very few, if any, security audits will take specific selinux policies into account. If they do, it would be in addition to native OS controls. And by native, I mean typical UNIX file-permissions. Many of these tests run across multiple UNIX platforms... Solaris, AIX, BSD, and Linux. A linux-specific feature like selinux is unlikely to be taken into account.

Files should be owned by the functional account that the application runs as, with permissions limited to the functional owner and it's group, and access limited to those only (in most cases).

Your customers concern may not be tied to a specific threat model as much as it is simply considered best-practice and the ability to pass an audit.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .