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
This archive was generated by hypermail 2.1.3 : Sun Jan 15 2006 - 13:43:16 PST