[clue-admin] Please review Member Accounts Plan on the wiki

[Collins Richey]

On Thu, 06 Jan 2005 09:17:30 -0700, Ronald Kuetemeier
<ronald at kuetemeier.com> wrote:
> On Wed, 2005-01-05 at 22:50 -0700, Collins Richey wrote:
> 
> > But, after reading about the authorized_keys file, it would seem that
> > users with write access to this file could insert keys with almost any
> > command and thus subvert the security setup? Would you comment on
> > this, please. Could this be used to get a "real" shell on the account?
> >
> > Thanks for the comments.
> 
> Let me chime in here. This is how I would attempt it, never tried it
> might work or not.
> First if you just start bash, I guess that wouldn't work. Since there is
> no direct way to talk to bash. But you can run any command your allowed
> to run on the system  according to the permission, or selinux or kernel
> security module or chroot or what ever "evil" admin  you through in my
> way.
> Now let's take a look how we could do it.
> First we write a little program which installs a root kit after it's
> executed, now we load this program up to your server.  It won't run
> since the permission will not allow it to run. So we need to change the
> permission and then run it.  

[ rest of scenario snipped ]

Yes, what you describe is technically feasible. That's the main reason
we do not intend to permit any sort of a general purpose shell in the
members environment.

Using sftp-server as the "shell" will isolate us from directly invoked
attacks, since the user can't do anything more than sftp commands, but
there are some combined exploits that may secondarily make use of sftp
to solidify the attack. If the attacker can rootkit the system, then
of course it can substitute malware in place of the ssftp-server, etc.
sftp-server unless wrapped, does not set umask, so users could upload
executables.

There is an excellent article that provides a lot of usefule information, namely
http://www.securityfocus.net/infocus/1404.

One fairly simple change recommended by the article is to mount /home
as a separate partition and to preclude programs from executing as
setuid on that mountpoint. Beyond that, we probably should not have
administrative users in the same /home partition as members.

Keep the discussion flowing. We'll get it right yet.

-- 
 Collins