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

[Ronald Kuetemeier]

On Thu, 2005-01-06 at 09:56 -0700, Collins Richey wrote:
> 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.
> 
Well mostly right. But. 
Or how badly do your users need dir's they can create and use.
Take a look at the attached file. Look at the perm and the beginning
(command) of the key in  authorized_keys2(yeah I know, but it's a
specified name anyway) .
Anyhow this also prevents scp or for that matter any other command from
running only sftp works. So in theory the umask could be more liberal
and allow the creation of dirs with the exec bit set since sftp will not
run any other command and therefore you could allow it.  This umask is
just for the really paranoid.
 Just a little bad trick.
Ronald


> 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.
> 
-------------- next part --------------
ls -la
total 56K
drwx------   4 test test 4.0K Jan  6 17:46 .
drwxr-xr-x  11 root root 4.0K Jan  6 16:54 ..
-rw-------   1 test test    5 Jan  6 17:03 .bash_history
-rw-r--r--   1 test test  302 Nov  5 09:54 .bash_logout
-rw-r--r--   1 test test  191 Nov  5 09:54 .bash_profile
-rw-r--r--   1 test test  124 Nov  5 09:54 .bashrc
-rw-r--r--   1 test test  383 Oct 18 05:34 .emacs
-rw-r--r--   1 test test  120 Oct 19 14:28 .gtkrc
-rw-r--r--   1 root root    0 Jan  6 17:46 ls.txt
-rw-r-----   1 test test 4.7K Jan  6 17:24 perm-test
-rw-r-----   1 test test   90 Jan  6 17:30 perm-test.c
drwxr-xr-x   2 root root 4.0K Jan  6 17:23 .ssh
drw-r-----   2 test test 4.0K Jan  6 17:24 test
total 4.0K

ls -l .ssh
-rw-r--r--  1 root root 680 Jan  6 17:23 authorized_keys2

cat .ssh/authorized_keys2
command="umask 0137 && /usr/libexec/openssh/sftp-server",no-pty ssh-dss AAAAB3NzaC1kc3MAAACBAPQlbvZ1oezSu9gr5AtJ/mzum3ggNBq9eaM4L5kW+g1/wi+7ML+t3lEHx9qrA3lGndqeeJ3EOLNK0K3O4ExhxMpxHkR3IZIRX+U68+uc2bHn24PYYPPVmNmIoW4yRwgxecEkSee7ab+md+RMnWr8XxOrMqXa5KVHrHmrZBLF7bA3AAAAFQD3Ixomguyq1p1cW6exuVB+Oo68DQAAAIAKLq/dUy2SJ525F86s6EfrxiEfj9kyNyuKQJvMtXh8k5ojbKDfCk1YHXXCiLTHoyNJ3LM5BaymeyYRpMIRmlX9hCQ9mLMCGdG5EgfUIdEiSpLVD4dmg+0VkKF4q8Gsw3EzA4b/JyHqhqX0i/+t9VCP7NJ7YWlqfuS8Wwywa20LTwAAAIAXZQoycePF+gF2QnLonEcv0gOBzLtZu4L9oFxkZEqs6RsjFJmZMqopFeFPQ2vh8xa5ZWgZlEHm/nDqSeBfTklU10GXY9iJeZXH5UIFPGS82AaqeWbkKABCNVazDDWY3dN+tCennJ1MVFN0fIBjnKsgdcDGnZutetmDPztqRZfnFw== test at ronald.kuetemeier.com