loading...

CentOS 7 – Restricting access to su or sudo

How to Install Intellij IDEA on Windows 10

We can restrict a user from running the su or sudo commands by changing the user’s SELinux user mapping like this:


semanage login -a -s user_u test

The preceding command will change the Linux test user’s mapping to user_u and will not allow the su or sudo commands access.

Note

This will only take effect when the user is not logged in.

Restricting permissions to run scripts

To restrict the Linux test user’s ability to run scripts we have to do two things. First, we change the user’s mapping to guest_u, the same way as we did previously:


semanage login -a -s guest_u test

By default, SELinux allows users mapped to guest_t to execute scripts from their home directories. We can confirm the same using the following command:


getsebool allow_guest_exec_content

It will show that guest_exec_content is on. So, the second step is that we disable the guest_exec_content using this:


setsebool allow_guest_exec_content off

Now, the test user for whom we changed the mapping won’t be able to execute any scripts even if he has full access to his home directory and the files that he creates there.

If we do a grep to see what SELinux is preventing /var/log/messages, it will show us the access denial along with an alert ID. We can note the alert ID and run:


sealert -l <alert id>

It will show us full details about the access denial along with some suggestions to remove it as well.

Restricting access to services

Assume we have a user admin with access to sudo so that it can run commands with sudo to start and stop services like httpd. Now, even if the user has sudo accesses, we can stop him from management access to services by changing his user mapping to user_u, the same way we did before:


semanage login -a -s user_u admin

This will restrict the user admin from restarting or stopping services.

We can verify the user_u access info by running the seinfo command as the root:


seinfo -uuser_u -x

This output shows the roles user_u can have access to; they are object_r and user_r.

Let’s go one step further and run the same command to find out what domains the user_r role is authorized to enter:


seinfo -ruser_r -x

There is a long list of domains the role can enter. Now, let’s find out whether the role can enter the domain httpd_t by just filtering the output with grep:


seinfo -ruser_r -x | grep httpd_t

This will return nothing, which means that the user_r role is not authorized to enter the httpd_t domain, and therefore, it is unable to start the httpd process or daemon.

Comments are closed.

loading...