[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20020828010359.A14332@openwall.com>
Date: Wed, 28 Aug 2002 01:03:59 +0400
From: Solar Designer <solar@...nwall.com>
To: owl-users@...ts.openwall.com
Subject: Re: [sOT] General security/permissions issues (long)
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
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.
