Using Client/Server model for security
MOTTO: 2 fences are harder to jump than only one.
In previous chapters I explored the possibility to use a client/server model
in order to increase both the security of the system and the system flexibility.
Now, I will take a deeper look at the design model.
Until now, we have a server (running with maximum possible privileges) and a set of
trusted clients who are allowed to obtain protected resources from the server and/or
ask the server to perform privileged actions in their behalf. This approach have huge
advantages over the actual models involving setuid root programs or launching
programs with setuid helpers. These advantages are:
= The trusted program act as a filter betwen user and server. In order to generate a buffer
overflow in server to start a shell with root privileges, the attacker should first pass
the security checking provided by the trusted program. While I don't claim that it is
impossible to send malicious code to server overpassing the trusted program checking,
this is however a more secure approach than letting the user to interact with a setuid root.
The attacker have to find a set of data that generate a buffer overflow in server and it is
recognized as valid data by the trusted program. Since usually the trusted program will parse
the input by itself, validate it, then generate the query to the server the job of overflowing
the server become much harder.
= When the trusted programs start to process the data provided by the user, it already run
with the user privileges. Since the trusted program may mark it's protected resources with
close on exec flag an eventual buffer overflow may not get any protected resource.
= Even if the trusted program may be fooled to overflow without closing some resources,
these resources will be the only resources the malicious user may compromise, and not
the hole system.
= The only way of attack that can succeed on the model is: a code injection into the trusted program, code
who override the trusted program flow and perform unwanted actions.
However, not just this attack is much harder to achieve than a single BO of a setuid root,
but the damages that can be done may be minimized as I show bellow:
We can have 3 different weight distributions betwen client and server:
- Fat Client with Thin Server
In this model, the server will allow any protected resource to be accessed by any
trusted program independent by the user who run it. The decision of what
operations/resources are allowed to be used by a particular user belong to the trusted client.
This mean, that the server will honour any request done by any trusted program regardless
what program it is or what user run it.
This model have the advantages that the implementation is easy both for client and server.
The server will be small and the client can reuse existent PAM authentication modules for
access control. The disadvantages are that the attack presented before, will
provide the system wide access to the malicious user. However, even this model is better
than what we currently have.
- Medium Client with Medium Server
In this model, the server is somehow made aware about what the program was designed to do.
Then the server will provide to the client only and all the resources the client may need
to do his job. Then, it is the responsability of the client to check if a particular user
have the right to do all the program capabilities or refuse some of them. The advantage over
previous model is that even if an attack is successfully, the attacker may get only a limited
set of resources available, and the client can still use old PAM for more controll.
I personally don't see any disadvantage.
An example will make the things look more clear: Let's assume the
program we talk about is ping. This program require raw socket access, possibility to get
information about network interfaces, and ability to start/stop a specified interface.
When the program authenticate to the server, the server know that the only tasks this
program is allowed to request are open raw socket and interface control functions. If the
program request an opened /etc/passwd or the sendmail port not just the server will refuse
to provide it these resources, but it know that something is very wrong with this program
so it can start an "investigate" script to "take care about problem".
- Thin Client with Fat Server
In this model all the access controll responsability belong into the server.
The server will have a ACL system based on which it can decide what resource is allowed
to request each trusted program running in behalf of each user/group. Which programs are
allowed to start each trusted programs, maybe even hours of access and so on.
The advantage are: an unique point of controll for access (the server ACL), very granulated
controll over resources and tasks. On the previous example in medium model, it was the client
responsability to decide if a particular user is allowed to stop a particular interface. If the
client was hacked, the hacker had the possibility to activate/deactivate any network interface.
In this model, the server will prevent him to do so. Also this model may enable control like:
the seniors administrators may be allowed to start/stop any interface, the juniors administrators
may start/stop only the interfaces with the trusted network and the rest of the users may not
activate/deactivate any interface. Or it may enable the group administrators. I.e. The admin
for planning group will be able to add/del users within planing group rights but will not be
allowed to touch a user from computer department.
The disadvantages are that this model is a radical change and the existing PAM support
can't be reused. The server code will be complicated and will take long time to implement,
test and bugfix.
I will start with 2. Medium Client with Medium Server, but with intention to provide support
for building a full 3. model later.
The installation program create a database used by the server.
This may be the first small step toward 3. Each trusted program kit come with a XML file
describing the client and the resources it may need. The client authenticate itself
based on a unique name specified in this file, and the server use the file to grant
the access. Later, this file may also require to be signed with the PGP key belonging to
one of the administrators of the system. Or with a key belonging to a vendor, who is declared
(by e-signature of system owner) as trusted enough to install trusted programs.
Back to advanced Advanced Unix programming techniques page
Sys++ Project Home page
Visit M.T.M. Home Page