Introduction to AUTH

What exactly does the AUTH module do?

As we saw in the introduction the AUTH module is responsible for user authentication. It also provides a range of other authentication related controls. These include controlling which objects are allowed to change their uid, which objects are allowed to set their Linux Capabilities, etc.

Anatomy of an RSBAC error message

If you were to have a look at the output of dmesg you may be horrified to see entries like the following:

				0000001459|rsbac_adf_request(): request CHANGE_OWNER, pid 3997,
				ppid 3994, prog_name sshd, prog_file /usr//sbin/sshd, uid 0,
			    remote ip 10.0.0.73, target_type PROCESS, tid 3997, attr owner,
				value 1000, result NOT_GRANTED (Softmode) by AUTH
			 

This is providing us a wealth of information, some of which is worth mentioning here before we perform any configuration.

0000001459

The RSBAC sequence number. Each event is assigned a sequential number to ease the detection of log tampering.

request CHANGE_OWNER

This is probably the most important component of any RSBAC message. It indicates what the object was attempting. In this case it was attempting to change the owning uid.

pid 3997, ppid 3994

These are the process id and parent process id respectively.

prog_name sshd

This is the name of the program which generated the event.

prog_file /usr//sbin/sshd

The full path of the program file. As can be seen here there are sometimes extra / characters in the path. These can be ignored.

uid 0

The user id of the current owner of this object.

remote ip 10.0.0.73

The remote IP address of the owner of this process.

target_type PROCESS

This indicates the type of object that the target represents. In this case it is a process.

tid 3997

The id of the target. In this case, as the type of target was specified as PROCESS in the previous field, we know that it is a process id. We can see from the process id provided above that it was trying to modify its own uid.

attr owner

This indicates which attribute the object was attempting to modify. In this case it was the process owner.

value 1000

This is the new value which the object was attempting to assign to the attribute mentioned previously. As we know it is a uid we can determine that it is the user Max.

result NOT_GRANTED (Softmode)

This indicates that the request was not granted. It was permitted however as we are running in "soft" mode.

by AUTH

This allows us to see which module was responsible for rejecting the attempted operation. In this case it is the AUTH module. We shall use this field later when we configure logging to allow us to separate the log messages into different files.

Fixing sshd and the login prompt

Now we know that there is a problem with sshd, and that it is caused by the set_uid restrictions enforced by the AUTH module, we can do something about it.

As we can see from the above log entry the sshd process is attempting to change its owner id to that of the user who is logging in. This is obviously a perfectly normal thing for the ssh daemon to do so we should configure RSBAC to allow it.

The rsbac-admin package provides a dialog based application called rsbac_fd_menu which will be of use to us here. It allows us to configure the RSBAC options for Files and Directories.

RSBAC is rather picky about who does what, as one would expect from a security system, and will only allow the Security Officer to change the permissions granted to objects. Thus we need to start by logging in as the Security Officer. This will work while we are in "soft" mode even though we haven't set the permissions yet.

secoff's RSBAC password: 

While running in "soft" mode we can do this kind of thing as root, or possibly even other users, but it is always a good idea to get in to the habit of doing things correctly right from the start.

 

Now that we are logged in as the Security Officer we can modify the permissions for the ssh daemon.

We are interested in the option which controls the set_uid system call which at the moment looks like this.

Change it so that it looks like this.

Don't worry about the other options for now. We don't need to set any of them yet and we shall be introducing them as we need them.

You can now do the same for the login prompt.

Don't be tempted to do the same for /bin/su as this would allow root to change to the secoff account without a password which would defeat the point of RSBAC. If you want root to be able to su then don't panic, we'll cover that in a later chapter.

 

That is it for the AUTH module for now.

Congratulations! You have just set your first AUTH policies.