On Mon, Aug 26, 2002 at 10:08:54PM +0400, Michael Tokarev wrote: > 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. We don't intend to avoid SGID entirely. It's only SUID which we'd like to get rid of (not the support, but uses by Owl itself). It already is possible to run a reasonable multi-user Owl system without any SUID binaries and plans on how to to make more functionality available in such a setup are being discussed on owl-devel. SUID to either root or non-root grants more privilege than is actually needed in almost all cases. The latter because the non-root user would be granted control over the inode and file contents, unless filesystem-specific attributes are used. The latter are undesired because they may not survive backups and, with current Linux/ext2fs, restrict more than is needed for this kind of use. SUID to non-root is also almost always easily replaceable by SGID. > 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. This is the one I'd prefer. > - 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. - 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. > Or maybe there is another, different way exists? Nothing major that I'm aware of, you've summarized it all pretty well. > I think this sort of problem(s) exists in many different > situations. Indeed. -- /sd
This archive was generated by hypermail 2.1.3 : Sun Jan 15 2006 - 13:43:16 PST