Re: [sOT] General security/permissions issues (long)

From: Hank Leininger (owl-users@progressive-comp.com)
Date: Thu Aug 29 2002 - 08:37:40 PDT


On 2002-08-27, Solar Designer <solar@private> wrote:

> On Mon, Aug 26, 2002 at 10:08:54PM +0400, Michael Tokarev wrote:

> > 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:
[snip]
> > - maybe some more I've missed.

> - have the remote connect as root, with two different su -c forced
> commands in root's authorized_keys.

> This would avoid the two connections, but would risk full root access
> in case of bugs in the forced commands (actually a script) or in more
> parts of sshd.  The "bugs" in the script could actually be your not
> knowing certain assumptions the invoked commands might have, such as
> their trusting stdin for some sort of prompts.

What about:
- Create a named pipe to which drwebb has write access, and drwebd read
access.  Have a long-running daemon running as user drwebd which blocks
forever reading it.  When something is received on the pipe, eat it, send
SIGHUP to drwebd (possibly enfocing a rate-limit to avoid CPU-hog DoS), and
restart the blocking read on the fifo.  When drwebb wants to update
signature sets, it first scp's all into place, and then writes to the named
pipe--possibly just make that the last "file" which gets transferred; scp
will copy to fifo's.  This also makes it clear when file-transfers are
complete as opposed to a cron job waking up and HUPing during mid-transfer,
etc. (Barring the source system running multiple overlapping scp's.)  Said
daemon would be very simple, thus easy to write/verify.

--
Hank Leininger <hlein@progressive-comp.com> 
  



This archive was generated by hypermail 2.1.3 : Sun Jan 15 2006 - 13:43:16 PST