On 5/16/2016 12:40 AM, Datta, Souvik wrote: In an embedded system you generally have the system processes and some small, finite set of applications. You generally care about protecting the system from the applications and the applications from each other. You don't need (or want) to protect the system processes from each other. It is much simpler to create a Smack domain for the system and a Smack domain for each application than it is to write SELinux policy for every system process as well as each application. As for a performance comparison, it's difficult to say, given that we don't have two systems with "equivalent" policies to compare. SELinux policy for a simple system will be larger than a Smack policy, but the SELinux crowd will argue that the simpler Smack policy isn't as secure. More people are learning how to write SELinux policy, but it's very difficult to get right. The Android experience indicates that most people who are writing new SELinux policy will create something that will make a program run, not something that provides any security. Someone with a system perspective has to come in after the fact and ensure that the policy meets the system security objectives. It is possible to create a Smack policy that is every bit as granular as an SELinux policy. The policy used in Tizen 2, for example, puts each system process into it's own domain, and each "resource" into a domain. The lesson learned is that granularity leads directly and invariably to complexity. Hence the "three domain" model of Tizen 3. As always, it's better to design the security model of your system than to jam a pile of independent "secured" components together. Which would you feel safer behind, a wall made of ten 1000 pound stones, or 5 tons of sand?