[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <3D6A6EB6.7BC2F894@tls.msk.ru>
Date: Mon, 26 Aug 2002 22:08:54 +0400
From: Michael Tokarev <mjt@....msk.ru>
To: owl-users@...ts.openwall.com
Subject: [sOT] General security/permissions issues (long)
This isn't *strictly* related to Owl, but I'm asking
this question here since Owl is the only unix-like
OS that tends to avoid any setuid/setgid applications.
The "problem" is best illustrated using an example.
Here is a particular example of a setup that is in
use here in our own systems.
We're using a virusscanner application (DrWeb here)
to check all mails for possible viruses. There are
two separate (system) accounts created for this --
one for drweb daemon (drwebd) and another for it's
client - drwebc - an app that is called by an MTA.
Both shares the same group, drweb.
There is a directory, /var/spool/drweb/tst, where
drwebc places temporary (mail) files. This directory
is set up as follows:
drwxr-x--- 2 drwebc drweb 1024 Aug 26 21:41 tst/
That to say: only drwebc (client) can write to it,
and only members of drweb group can access files
within it. Files are created with mode 0640, group
drweb (user drwebc, obviously).
This all is set up in order for drwebd to be able to
*read* those files but not to modify them (by a chance),
and so all other uids in system cannot access this
directory _at all_. I.e. only absolutely necessary
privileges are given for every party.
Also, drwebd user itself is protected from drwebc (client)
so it's not possible to e.g. send any signal to a daemon
and so on. Drwebd's listening (control) socket placed in
separate directory with similar permissions but owned
by drwebd (not drwebc).
The tst/ directory serves just as an example. This
part is working just fine as it should. Ok, now the
question.
There is another directory, bases/, where all av bases
(*.vdb files for drwebd - virus signatures) are keept.
This directory should be readable by drwebd - obviously -
so that daemon can read it's data. But it should NOT
be *writable* by daemon: if by any chance an attacker
will have control over drweb daemon (a complex piece
of software, closed source, yadda-yadda), he should NOT
be able to mess with those. For now, directory bases/
and all files within is owned by root:root.
Those virus signatures should be updated regularily.
So I periodically checks for new signatures from another
machine, test any new ones found, and upload good ones
into production machine. Drweb daemon should be HUPed
in order to recognize new signatures. This may happen
several times per day - i.e. frequently enouth.
This whole task is done currently as root on target
machine. This is not good, obviously, *especially*
if this task will be automated (as it really should
be).
Ok, so I created another uid, e.g. drwebb (bases),
chowned bases/ directory to be owned by drwebb, and
created authorized_keys file in drwebb's home directory.
Ok, now drwebb can update virus signatures and drwebd
can't -- exactly what it needed.
But drwebb cannot reload drwebd - it can't send SIGHUP
to a daemon due to permission problem.
There are several possible solutions:
- periodically check for updates in bases/ using cron
with uid=drwebd. Ugly, since I know for sure *when*
updates are made.
- connect to a target machine as user drwebd (place
the same authorized_keys with another forced_command)
just to send sighup to drwebd. (Note that drwebd user
cannot *start* a daemon, root permissions are needed
for this since a chroot call is involved here). Also
ugly enouth (two separate connections are needed) but
it seems this is the most perfect solution.
- make bases/ owned by drwebd (not by separate drwebb).
This may (somewhat) open a system to an attack. But
this is most simple and strightforward way.
- make setuid drwebd binary and made it runnable only for
drwebb user, - a binary that will only send sighup to
drweb daemon. Contradicts with Owl way.
- maybe some more I've missed.
Or maybe there is another, different way exists?
I think this sort of problem(s) exists in many different
situations.
/mjt
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
