If you're looking for a way to control or restrict access to your Linux-based applications, you might want to look at SELinux. This extension has been around since Linux kernel 2.6 and can help you with your access issues.
A few technical terms need to be introduced to ease things later on. A while ago we mentioned that security labels or so-called contexts are associated with initiators and targets. File_context is the security label associated with files (objects) and domain when we talk about processes. The bottom line is that these contexts are located within inodes. The context is built up, usually, by four components. Let's see which ones these are.
The first component is the one specifying which group the roles are part of. These can be system_u, user_u, and root. Processes not executed by users (i.e. that are run during the boot-up process) are commonly associated with system_u, while user_u is the default user for logged-in users, and the root is self-explanatory.
The second component stands for the role field. This component is negligible in the case of files (it's always object_r but irrelevant) since they are specifically useful on domains (i.e. processes). By convention, these end with "_r" just as the users that we talked about in the paragraph above got the suffix "_u". A few role examples include sysadm_r, staff_r, etc.
The third component is the type. It ends with "_t." This field represents the basis for the type enforcement functionality of SELinux. An example of a policy that uses this kind of type enforcement is specifying which type of initiators have access to which kind of object types. The last component is the MLS component, and on most targeted or strict machines, it's"s0" by default, which can also be "". It's quite irrelevant to us.
Ever since the Linux Security Module (LSM) became integrated into the kernel as a general-purpose model, SELinux could be implemented to work on top of it, without being required to be shipped as a set of patches and extensions of its own. The appearance of LSM brought with it lots of possibilities for enhancement, since it enabled stacking of security models. This way it helped along Linux security's modularity.
Aside from the previously-discussed mandatory access control solution, SELinux also makes it possible to work with role-based access controls (RBACs). Roles differ from groups in various shapes. For example, a role stands for users, but also for permissions that specific users are able to perform. In the case of groups, programs are given the least privileges to perform their own tasks, but just that. This is based on MAC.
Understanding and finding your way around SELinux policies requires research. We recommend that you look through the man pages of policies and check a few of the SELinux-specific commands for your distribution. You need to monitor and understand access vector cache (AVC) messages. These can be found inside /var/log/messages or /var/log/audit.log. These are verbosely logged, and you can find out what happens inside.
There are really useful auditing tools that help you with understanding AVC log messages. Such tools are audit2allow and audit2why. The first generates allow-rules based on the logged denied operations, while the second answers the "why" question by analyzing the denied audit messages and transcribing them into a descriptive format.
As a final rule of thumb, get familiar with the "Z" kind of Linux commands, such as the "ls -lZ" or the "id -Z", and many others. Managing file labels is also another concept we'd advise looking into. On another note, applications might fail without any AVC message traces. Policies can also be created with booleans (if/then/else).