Hey everyone! I'm working on creating an SELinux policy that prevents a specific user from executing shell commands (like bash, ksh, etc.) for security reasons and to learn more about SELinux. I've based my approach on some code snippets I found, but I'm running into syntax errors when using the 'checkmodule' command on my RHEL 8.10 VM, specifically regarding the 'deny' token.
Here's a bit of context: we have a secure account (let's call it 'secure_user') that I want to protect. Other admins can gain access to this account via sudo commands, but I want to ensure that they can't start a shell session with it. The goal is for the specified users to run certain commands as 'secure_user' without ever being able to launch a shell.
Here's my current code:
```
module user_secure_role 1.0;
# Define the new role
role user_secure_r;
# Define the new type
type user_secure_t;
require {
type shell_exec_t;
}
type_transition user_secure_r init_t:process user_secure_t;
deny user_secure_r shell_exec_t:process { execute };
```
When I run `checkmodule -M -m -o user_secure_role.mod user_secure_role.te`, I get this error:
`user_secure_role.te:19:ERROR 'syntax error' at token 'deny' on line 19: deny user_secure_r shell_exec_t:process { execute };`
Is there something else that I need to install on my RHEL system to make this deny function work? Any insights or guidance would be greatly appreciated!
3 Answers
Have you thought about using ACLs instead of delving deeper into SELinux? Normally, setting the shell to `/sbin/nologin` works for blocking shell access. I get that you're looking for something more rigorous for compliance reasons, but it could simplify things for you. Here's a quick loop you can run:
```
while read -r; do
setfacl -m u:${bad_user}:r-- "${REPLY}"
done < /etc/shells
```
I tested on an Alma system and it worked flawlessly!
I understand the ease of ACLs, but they do have manageability issues. Plus, they might require frequent updates for new users, which can be a hassle. Going the SELinux route might seem complicated, but it offers a more permanent solution to restrict privileges.
You might be working off outdated documentation. The 'deny' keyword isn't a part of newer SELinux implementations. Try refactoring your code like this:
```
module user_secure_role 1.0;
role user_secure_r;
type user_secure_t;
require {
type shell_exec_t;
class process { transition };
class file { execute };
}
role user_secure_r types user_secure_t;
type_transition user_secure_r init_t:process user_secure_t;
// No need for allow rules; execution is denied by default.
```
Let me know if you face any more issues while running it!
That makes sense! I'll give this adjusted version a shot. I'm facing an error now about an 'unknown type user_secure_r' — am I defining it correctly at the top?
You're on the right track! Just make sure 'user_secure_r' is declared correctly and matches your requirements. Keep me posted on your progress!
Good call on investigating further! But just a heads up, trying to block shells can also interfere with running shell scripts, since bash is the common interpreter. You might need to rethink the approach to still allow scripts while denying shell access.
Definitely consider the security side. While ACLs work, we want to restrict access as much as possible for sudo accounts. SELinux's approach may seem tough now, but it offers long-term stability against changes.