On a classical Unix system the user root (UID 0) has all the
permissions
Hence root can read all files and kill every process
If a program needs a special permission it must have the identity
root.
For example a backup program only need read access to all files
By running as root he gains total control of the system and can kill
every process.
Capabilities are the partitionning of the root permissions/privilege
into a set of distinct privileges: ex: CAP_SYS_TIME: capability to set
time.
Capabilities are listed in /usr/src/linux/include/linux/capability.h.
2.2 Linux's Capabilities
The capability system used is definied by the POSIX draft 1003.1e
"POSIX capabilities" wich is now obsolete
At this time only the processes are associated with capabilities
Two projects are actually in progress to manage the capabilities of
executable files.
There are three set of bits for each capability that can be associated
with executable files:
permitted(P): the capabilities that can be used by the process
effective(E): the capabilities effectively in use at a
certain time (the process can choose to use or not the capability)
inheritable(I): the capabilities a process launched with
exec will be masked with. (fork and clone processes have exactly the same
capabilities as the parent)
2.3 Processes Capabilities
In the kernel 2.2, no reference is made to the process's UID. In order
to know what permission the process has only the effective (E)
capabilities are checked.
On a classical Unix system, processes owned by root have all the
permissions and the other processes have none.
The CAP_SETPCAP capability allows to change the capabilities of other
processes.
In linux 2.2 this capability is not given to any process.
To have a system using capabilities you have to change two lines in
the kernel sources(see CAPFAQ). Processes owned by root will
then have this capability.
Since kernel 2.2.11, the list of all capabilities is viewable from the
file /proc/sys/kernel/cap-bound
lcap, which can be found at
<http://pweb.netcom.com/~spoon/lcap/>, makes it easy to remove
system capabilities (those obsolete and those you don't want)
2.4 Setting capabilities to processes
Use the execcap utility to start a process with a limited set of
capabilities:
execcap <caps> <command-path> command-args...
Will execute a tamagoshi server on priviliged port 999.
Process runs as root but can only use priviliged ports
If a vulnerability appears in the server, it could be used to gain
access to files owned by root.
Use the sucap utility to start a process with a limited set of
capabilities and to specify the user and group ID the program should execute
as:
Will execute a tamagoshi server as user tama of group tama but has
capability to open priviliges port
If a vulnerability appears in the server, it will only enable access
to files owned by tama
Caution: In some cases the file will start executing itself
without having it's capabilities granted. This will disapear as soon as
capabilities will be managed at the file level.
2.5 Setting capabilities to executable file
Two tools are actualy in developement:
fcaps: VFS layer patchs for capabilities
enables to grant capabilities to executable files
the capabilities granted are recorded in the file system
Ex. with ping wich needs the CAP_NET_RAW capacity:
ping doesn't need to be SUID anymore
Ping will have the ID of the person who uses it
elfcap: Elf capabilities hack
enables to suppress capabilities to any executable file in elf format
all the capabilities are stored in the elf header.
Ex. with ping wich needs the CAP_NET_RAW capacity:
ping must be suid root
If the administrator uses the correct options while defining the
capabilities granted, then the program takes the ID of the person
who executes it.
"Weakening the Linux Kernel" (Issue 52 article 18)
by plaguez
<dube0866@eurobretagne.fr>: description and sources of a
backdoor initialised by a module.
"btrom" (Issue 54 article 03)
by riq: description and sources of a program of detection and
deactivation of backdoors.
Based on a Slackware distribution with a 2.0.36 kernel, it includes
several security patchs for the kernel: "Solar Designer's patch",
"Trusted path support", "Probe Detection Patch"...
A script to harden acess rights to numerous sensible files.
The project consists today in a script that tighten a system under
Redhat 6.0 et 6.1: acess rights to sensible files and security parameters
of applications.
The 1.1.0 version is available since june, 7 of 2000 and is extensible
to other distributions.
exploitation of security vulnerabilities are generally of this kind.
A version of RedHat 5.2 entirely recompiled with Stack-Guard is
available.
Is a complementary approach to:
Using a non executable stack
Auditing source code
The 2.O version of Stack-Guard is a port to egcs 2.91.66 and an
Immunix OS version 6.2 based on a Red Hat 6.2 is available.
Nexus Linux<http://www.lemuria.org/Nexus/>: is a distribution indented
for administrators who's first concern is security. It comes in standard
with Openssh and ssl support for apache.
slinux<http://www.slinux.org/>: is a distribution intended to be
more complete than all the others, it should integrate privilige management,
partition cipherening, ...
Historically, authentication of Unix users relied on the input of a
password wich was checked with the one stored in /etc/passwd .
At each improvement (/etc/shadow , one-time passwords...)
each program (login, ftp, ...) had to be rewritten.
PAM is a more flexible user authentication mecanism.
Programs supporting PAM must dynamically link themselves to the
modules in charge of authentication.
The administrator is in charge of the configuration and the
attachement order of modules.
7.1 Configuration
All applications using PAM must have a configuration file in
/etc/pam.d . Each file is composed of four columns:
Module type:
auth: user authentication
account: user restriction (ex: hour restriction, ... )
session: tasks to perform at login and logout
ex: mounting directories, ...
password: update of the user authentication token
success control:
required: a leat one of the required modules
requisite: all the requisite modules
sufficient: only one sufficient module
optional: a least one of the required modules is necessary if no
other has succeeded
path to the module: usually /lib/security .
optional arguments
the /etc/pam.d/other file provides default configuration for
all modules not specified in the configuration file of the application.
7.2 Modules
pam_cracklib: uses the cracklib library to check the
"strength" of a password and to check it was not built based on the old one.
pam_limits: this module can restrict, depending on the
user and/or group, the number of simultaneous processes, CPU time, the
number of files simultaneously opened, their size, the maximum number of
simultaneous connexions.
The configuration file is: /etc/security/limits.conf
pam_rootok: enables root to access a service without
using his password. To be used with chfn or chsh and not
with login.
pam_time: control the access time. The configuration file
is: /etc/security/time.conf .
pam_wheel: allow access to root only to users of the
wheel group. For use with su.
pam_cap: this module can force all privilges to a user.
® © Hervé Schauer Consultants 2000 -
4 bis, rue de la gare -
92300 Levallois-Perret