Examples of software configuration

-------------------------------------------

Here we take some examples to show how things can be tightened and what are
potentials of improvements. Please refer to the template setup in
etc/sysmask to see how things are done in reality.

The package comes with a template configuration setup. This template is far
from being optimized; many possible actions are not taken. The objective for
the template is to be as generic as possible.

As our goal is to take sound sleeps without being bothered by those constant
vulnerability alerts, in the following discussion we make the extreme
assumption that every program is vulnerable to the extreme: possibility of
execution of arbitrary codes. And we discuss what this worst-case situation
will mean to the global system integrity under sysmask protection. Of
course, the compromised program will cease to work, but the damage is
limited to the service itself if the global system integrity is preserved.
In this case, the compromised service can easily be restarted with little or
no permanent damage.

-------------------------------------------

We start by network daemons. In general, these should and can be configured
to disallow high-risk system calls (risk level above 4), possibly with one
or two exceptions, as well as manipulation of links, directories, mounts. So
we don't repeat these restrictions every time.

*named

This is among the easiest to configure. It needs extremely few system
ressources for its normal work, so local filesystem access can be almost
completely shut off, together with system calls of risk level 3 or up with
very few exceptions. Network socket access can be restricted to
communications with dns ports.

No permanent damage can be made to the system by a process under such
conditions. The biggest risk is for the service itself: it may be made to
serve erroneous name resolutions, helping attacks to other services.

*sendmail

This service is not much worse than named, because no special privileged
service is required for its normal work, and filesystem access can be
restricted to /var/spool/mail. Of course, network communication can be
restricted to smtp ports.

execve must be allowed, in order to execute definitions in users' .forward
file. But this execution can be done under another token, with tailored
restrictions: file write access limited to user's home directory plus maybe
/tmp, no system calls with risk level 3 or up except a few (fork, execve,
signal), strictely limited access to system executables, etc. smrsh is
now obsolete because sysmask offers a much better protection.

Moreover, users can now set up user-level restrictions to protect his
account against the risk arising from processing malicious emails. For
example, file access can be further restricted to specified subdirectories
of the user account.

Again under these conditions, the main risk of a compromise is the service
itself: the server may be used to make unauthorized outbound distributions
(spams), bad mails may be deposited to /var/spool/mail, or good mails may be
erased. Disk space may be filled in if quota and rlimit are not correctly set.

The biggest risk is obviously the distribution of spams. An easy solution is
to use the "tick" action of the configuration to set limits to outbound smtp
connections within a given period of time. But I suspect that few people
will be interested in doing so, as this risk "only" harms others.

*httpd

The processes need to access fork, execve, ipc, signals. Other resources can
be closed, and network access can be limited to already opened http and
https ports, plus eventually connections to a predefined name server. File
read access can be clearly delimited to where the web pages are. For sites
that offer file deposits, sysmask now offers the possibility of tightly
defined writable zones. If you do so, don't forget to limit the call types to
the write zone to "open" and "creat". Doing so may avoid people playing with
the zone by trying "rename", "unlink", "truncate", or the like. (Links and
mkdir are normally hard-masked.)

execve is needed only if execution of cgi should be made available. In this
case, suexec can be replaced (or overridden) by sysmask configurations. In
any case, cgi execution is better be done with a token switch, so that
different cgis can enjoy different protections. Also, this allows httpd
itself to have more restrictions, because resources needed by cgis need not
be declared for httpd itself.

Note that once you set the suid mask, suexec loses its power. So you must
take over its function by a "newuid=" or a token switching in the
configuration of the token.

Once thus configured, the risk of a worst-senario compromise of httpd
consists of disruption of service (of course), disclosure of contents
protected by .htaccess or http password (which is never meant to be really
secure), and the worst one is undoubtedly the disclosure of private site
keys for https.

The principle is very simple: when a process has both access to network
communication and to sensitive local information, the latter is potentially
in danger. To change this situation, httpd should be redisigned in a way
such that only one thread, with no network access and only a clearly secured
communication channel with other threads, has the right to read the private
site keys.

*sshd (and similarly ftpd etc.)

As for httpd, user login shells can (and should) be opened with a token
switch, so that sshd can be masked for the need of sshd itself, which is
easier than httpd. However, this time there is a big trouble, because it is
a process with simultaneous access to network communication and vitally
sensitive local data: /etc/shadow. Thus any vulnerability in sshd has the
potential of disclosure of /etc/shadow, which is obviously a very
unsatisfactory situation. Potential disclosures may also happen for the
private key of the server and eavesdropping on connected users.

One could do the same as for httpd, with a separate process with no network
access that has the right to read /etc/shadow. But this doesn't really
improve the global security situation, as the authentication algorithm still
allows dictionary cracking. A real solution should be the creation of a
special daemon, say logind, who will be the only daemon having the right to
read /etc/shadow, with all other authentication processes directing password
checks to it. A better algorithm disallowing dictionary cracking can then be
implemented on this daemon.

However even this solution doesn't really interest me personally, because
now sysmask offers much better possibilities at no cost. Sysmask can be
configured in a way that the first login shell becomes a simple "quarantine
zone", with very limited access rights, exactly as for the sh method in the
security challenge. The challenge is showing that no damage can be done to
the system by letting unauthorized people access such a zone.

Now one can define special triggering actions as well as traps in the
sysmask configuration. See more discussions on this matter in the section
about customized authentication.

*crond and atd

These are not exposed except when they process "untrusted" commands. Of
course, this doesn't stop you from setting up a very tight policy for the
daemon themselves, then making differnt token switches when commands are
executed, according to the user who issues the command for example.

System-wide cron definition files should be made unaccessible by other
processes.

*X server

Personally I am using startx, so I haven't explored the situation of xdm. In
my case, the windows manager (started by a token "startx") is not very
exposed and in any case it is running as me, so this part is only mildly
protected.

Two token switches are defined in the startx token. One is for myself, when
/usr/bin/ssh-agent is executed. This gives me the token for my xterms under
which I am working.

The second is the crucial one: the "x" token, for the X server which is
running as root and has access to raw device drivers. This one must be
tightly controled because a compromised application might in turn attack it.
For this, normal file access is not very difficult. Using the debugging
feature, I take the access to the file /etc/hosts as the mark to the end of
the process startup. After that, not much is needed, so the process can be
protected as tightly as the other daemons. The real problem is its
unrestricted access to raw io ports, as the iopl system call is needed. The
problem is very serious: a direct access to network cards can bypass the
kernel firewall, and that to ide/scsi ports can lead to raw disk data.

A solution would be to split the server into separate processes, with iopl
being available to only one of them. Still better would be a special kernel
daemon that manages the accesses to io ports. In this way, one can manage so
that the X server has only access to video ports.

---------------------------------------------------------------

Now programs run by ordinary users:

*Mozilla, firefox, thunderbird

This software is very exposed to network risks. One must first disallow it
to install viruses and other malicious executables. This can be done easily
by disallowing write access except to the software's own directory.

Links should also be disallowed. Mozilla uses symbolic link to mark its
presence, therefore the link mask should be set using a trigger.

The next thing is to protect your personal data from reading by the
software. The best solution is to deny access to everything under the home
directory after a short exception list. In order for this to work
efficiently, escape preventions should not be forgotten: "hardlink", "follow",
and checkuid=nobody whenever possible.

Mozilla uses the system call sched_setscheduler, which is a bit strange for
a user level program. Personaly I deny this call, which does not seem to
notably affect the work of Mozilla.

The same is true for ipc system call which is a potential source of DoS.

Consider the possibility of setting kmod mask. Mozilla makes attempts to
install kernel modules, which should be denied whenever possible. There is
even a potential risk of kernel rootkit being installed in this way.

Orphan mask can also be set, to make sure that no virus will stay in memory
when you close the Mozilla window. And network access should be limited to
your name server, http/https/proxy ports, plus mail ports if you use it to
manage your emails. 

You can also use tick to set a limit to the number of emails each process
can send out, or even the number of connections of any type, if you don't
want people to turn your Mozilla into a spam/virus distributor or a DDoS
relay. If ever the limit is reached by yourself, you have only to close the
current window and bring up a fresh one.

After this, what remains as the main unprotect risk is the disclosure of
your personal data that are needed or managed by Mozilla itself: browsing
history, address book, email archives, and above all the register of your
connection passwords. The solution is again a slight redesign of the
software, with separate tasks running on different processes (not threads
whose shared memory area makes inter-thread contamination too easy) and
tightly checked communication channels between them. Each can be masked to
ensure that none can do any harm on their own. Before this is done, I can
only recommend not to let Mozilla save your navigation passwords. The risk
of identity theft is very important.

*Macromedia flash

It comes usually as a browser plug-in, and is a champion of espionage. A
malicious site can even exploit it to pilot your webcam without you knowing
it, sending whatever images captured to whatever sites the spy wants.

Now with sysmask, you can (and should) take the decision on what device
drivers you allow it to access, among other access restrictions.

*file readers: image viewers, acrobat reader, etc.

A reader is a reader. So no networking, no file writing. Under this
condition, they can be safely launched to read anything, including knowingly
bad files exploiting unpatched vulnerabilities of the program or a library.

It is rumored that Acrobat is incorporating spying technology into pdf. If
you don't like it, don't unset socknet for acroread. That's what I do
anyway: if the pdf refuses to open because of this, I trash it.

*file manipulators: openoffice, gnumeric, etc.

Turn off network access (or put strong restrictions), don't let them create
unusual objects (links, directories), and limit writing to files with
extensions recognizable by the software. And the risk you take by opening a
bad file is very limited.

Furthermore, if you don't want your own document file to be crashed or
altered by the malicious code in a bad document downloaded from the network,
take the habit of downloading untrusted files always into one directory.
Then tell sysmask to deny writing to your own document whenever a document
in the bad directory is opened. (You can use one of the 4 user masks to
achieve this.)

A special remark for OpenOffice: this software does not allow chmod mask
(whatever reason it is, I must consider this as a bad design point).
Therefore it has the potential to deposit executables (that is, viruses). So
care must be taken in the file access control not to allow simultaneously
writable and executable zones, at least when an untrusted document is
opened.

*wget

This (like many others) is a very useful program when launched manually, 
and a very dangerous one when automatically launched by an infected program
with no sysmask protection. 

If the program that launches wget is correctly protected by sysmask, wget
won't help the virus or exploit that compromises it, because the protection
is inherited by wget. So wget doesn't need specific protection of its own.
The same is true for the great majority of system utilities.