Issue creating an selinux policy

Posted by n5xjg@reddit | linuxadmin | View on Reddit | 7 comments

Hi Penguin Admins,

Im trying to create an selinux policy that will block a specific user from executing shell_exec_t (bash, ksh, etc...) for various security reasons - but also to learn selinux.

So Ive googled a bit and found this snippet of code that I modified on my RHEL 8.10 VM but when I try to run checkmodule on it, I get a syntax error about the deny token.

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 };

# checkmodule -M -m -o user_secure_role.mod user_secure_role.te
user_secure_role.te:19:ERROR 'syntax error' at token 'deny' on line 19:
deny user_secure_r shell_exec_t:process { execute };
checkmodule:  error(s) encountered while parsing configuration

I looked all around and even consulted AI and everywhere shows that deny is not a syntax error.

Do I need to install something else on my RHEL system to get the deny function to work?

Thanks in advance for any advice!

[-]

n5xjg@reddit (OP)

After further investigation, it was noted that blocking the shells also blocks the ability to run shell scripts because bash is the interpreter of shell scripts.

Sooooo.... I guess this cant be done LOL. Thanks for all the replies!

[-]

n5xjg@reddit (OP)

ACLs would work, but we need to make this as hard as possible for other sudo accounts to change the access to a specific user.

The reason is.... we have a secure account called secure_user (Obviously, thats not what its called, but for the sake of this...) and other admins can sudo su - secure_user or sudo -u secure_user /bin/bash and we want to prevent other users from accomplishing this.

We want them to be able to run other commands as the secure_user, however, like sudo -u secure_user some-super-secret-application or what ever, but NO ONE must ever start a shell with this user.

Ill add this to the original post also, so others can see what Im trying to do if there are other options for this.

We can block them using ACL's, sudoers, etc, but those are easy to do change with a root account. We want to start off using selinux so we can limit this user, and also make it very hard for anyone to change selinux.

Selinux, but its nature, as Im finding out, is extremely hard to work with HAH, so we though this was the best approach. Heck, Im a 24 yr Linux engineer with an RHCSA cert and have used basic selinux, but this stuff is super hard LOL.

[-]

dodexahedron@reddit

While I agree from the simplicity angle, ACLs do kinda suck from a manageability and durability standpoint.

First, there's the whole no indirect group membership thing that has always been a PITA limitation with POSIX ACLs and groups/users.

Then there's the ongoing/future need to apply the ACL for each new relevant user to which it applies or to make sure that they are added as a direct member of a group to which the ACL already applies.

Then there's the need to be sure that the ACL remains intact and in force across version upgrades, new shell installs, etc.

With a MAC policy denying the underlying privileges that make running any of those things possible, it will work for everyone, forever, including for situations that haven't been explicitly accounted for up front like using pipes to interact with the stdin/stdout file descriptors for the process representing the user when logged in.

ACLs of course can still be put in place, and it's not a bad idea to do so for sure. And the users should also have their shell set to something like /bin/false in /etc/passwd or wherever else their shell environment may be sourced from.

[-]

jaymef@reddit

I'd guess you found some old documentation because deny keyword only existed in older implementations of SELinux

Try something like this instead:

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 init_t;
    class process { transition };
    class file { execute };
}

# Associate the domain with the role
role user_secure_r types user_secure_t;

# Set up the type transition
type_transition user_secure_r init_t:process user_secure_t;

# No allow rule for shell_exec_t execution = denied by default
# DO NOT add: allow user_secure_r shell_exec_t:file execute;

[-]

n5xjg@reddit (OP)

Thanks! Yeah, I also found where deny was replaced with neverallow - who makes up this stuff :-D .

Anyway, so, when I run the new version, I get an error

user_secure_role.te:20:ERROR 'unknown type user_secure_r' at token ';' on line 20:

which is the line

type_transition user_secure_r init_t:process user_secure_t;

But arnt we defining that at the top?

# Define the new role
role user_secure_r;

[-]

jaymef@reddit

Full disclosure, I asked Claude AI about your new issue and this was the response. Take it as you will:

SELinux Role vs Type Confusion

You've identified the key issue: you're trying to use a role (user_secure_r) in a place where a type is expected. In SELinux:

Roles and types are different constructs
Type transitions need types in the source position, not roles

Correcting Your Policy

Here's a working version that addresses this issue:

module user_secure_role 1.0;

# Define the user domain type
type user_secure_t;

# Define the role
role user_secure_r;

# Associate the type with the role
role user_secure_r types user_secure_t;

require {
    type shell_exec_t;
    type init_t;
    class process { transition };
    class file { execute };
}

# Now use the TYPE (not role) in type transitions
type_transition init_t user_secure_t:process user_secure_t;

# You'll need some basic permissions for your domain
# allow user_secure_t init_t:process transition;

Understanding the Distinction

In SELinux:

Users are assigned to roles
Roles are authorized for types
Types have permissions on objects

Your type_transition rule should be between types, not roles. The role simply authorizes which types a user operating in that role can enter. Complete Implementation

For a complete setup, you'd need to:

Create a SELinux user
Map the SELinux user to your new role
Map a Linux user to this SELinux user
Add necessary allow rules for basic functionality