[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rssh-discuss
Subject:    Re: possible security problem in rssh
From:       Derek Martin <code () pizzashack ! org>
Date:       2005-03-09 16:08:49
Message-ID: 20050309160849.GA8884 () sophic ! org
[Download RAW message or body]

On Wed, Mar 09, 2005 at 11:53:42AM +0200, Shachar Shemesh wrote:
> Hi Derek,
> 
> It seems that we have entered a collision course. I didn't mean to, so 
> I'll try to start over. Please accept my apologies if I have offended 
> you in form or content.

I'm not at all offended.  And I hope you're not either.  =8^)  But I
am a little inclined to think that you're trying to use the wrong tool
for your task, or perhaps even trying to solve the wrong problem...

> Derek Martin wrote:
> >Well, it's in the FAQ -- I'd hardly call that hidden. 
> >
> You are right, except that when I tried to find it the second time 
> around, I couldn't. 

Fair enough.  I've been thinking about changing the contact info on
the web site...  Maybe I'll make it a link to the relevant FAQ
entry...

> Then again, human beings are fairly lousy at following rules.

All too true...

> I think our difference is based on the fact that you are assuming I'm 
> allowing sftp or scp. In reality, I'm allowing neither. I'm only 
> allowing rsync. I was looking for a way for users to be able to rsync 
> files into the machine, without being able to actually do anything else. 

On the surface of it, rssh seems to do that.

> I was also looking for allowing doing other, predetermined, stuff, hence 
> the second thread. Maybe rssh is not the right tool for this thing. 
> Maybe it just needs a little tweaking.

Perhaps.  The functionality you're asking for is similar to the
configuration of sudo.  That's a great tool...  It does, however,
suffer from a big problem: It's hard to configure limited access to
commands, and still be CERTAIN that the user can't get a shell.  This
is in part because so many commands allow you to shell, or allow you
to run arbitrary commands via some command-line option.  It is also in
part because so many system administrators either don't really know
their environment well, or simply aren't very careful when they are
configuring sudo.

I designed rssh quite specifically to avoid those problems.  If you
need it to do something it's not written to do, you're certainly free
to hack it.  But as far as I'm concerned, it does all it's ever going
to do.  I *might* consider adding support for svn, or for imapd
(because imapd was designed to be run via a remote shell in this way),
or some other specific command which is similar to these...  But
beyond that, rssh is done.

> Thing is, in my scenario, their "home directory" and ".ssh" are merely 
> administrative overhead, as far as I'm concerned. It follows that I 
> don't want them changing it.

It doesn't necessarily follow...  That is, I think it doesn't matter
if it changes.  If you *really* don't want it to change, you already
know what to do: don't include it in the chroot jail.

> You say you do not view that as a security hole. You may very well be 
> right. After all, it certainly not a security hole as far as pure Unix 
> permissions go. Then again, if we wanted to rely solely on pure Unix 
> permissions, we wouldn't have needed rssh.

Well, obviously rssh allows for a lot more restriction than simply
relying on Unix permissions...

> >It seems you're right, however you can set StrictModes to "no" (in
> >sshd_config) if you want the files to be owned by root.
> >
> Forgot about that one. Thanks.

No problem.

> >But I still don't see what difference it makes whether the users can
> >write their own versions of the .ssh directory.
> > 
> >
> Files in the .ssh directory control such things as the environment, 

Only if you let it.  If you set PermitUserEnvironment=no, it doesn't
allow the user to control their environment.  If you've read rssh's
docs, you know that this is necessary anyway if you want to run rssh
securely.

> whether or not port forwarding is allowed

You can control that on the server, by setting AllowTCPForwarding=no.
If you do that, it doesn't matter what the user's files say.

> the keys authorized to connect etc. 

I don't see a problem here...  In fact, I think the users NEED to be
able to change that, so they can change their keys without any
problems (and without the sysadmin intervening).  But that's up to
you...

> Then perhaps we are misunderstanding each other here. The way I 
> understand it, if this is not a security hole of rssh, then it is a 
> security mis-configuration of an administrator who wishes to do 
> something along the lines of what I'm trying to do. 

I don't agree...  I think it's a matter of trying to use a round peg
in a square hole, not a security issue at all.

> it. The exact meaning of what this is obviously changes with each 
> deployment, but I don't think I'll be too far off the mark if I said 
> that changing connection option is not something the admin would wish a 
> restricted user could do. 

They can't, if you don't want them to.

> Even if the last statement is not globally 
> correct, I think we'll agree it's a common scenario. A unix user account 
> used by several people to update a web site is one such setup that comes 
> to mind. 

Well, to be honest I don't agree, because I don't allow shared
accounts in the environments I administer.  This is what group
permissions were created for...  Or, rather, I suppose it IS common,
but it really ought not to be.  I can not be held responsible for bad
system administration practices in common use...  :-D

> This means that the administrator needs to be able to limit access to 
> the .ssh directory. The rssh documentation may lead one to suspect that 
> messing around with the config options can let you do that. 

I don't think it does...  If you disagree, please tell me what part
led you to believe that, so I can change it.

I suppose I could add a clear statement to the FAQ that outlines what
you're talking about, but I feel that I really shouldn't need to...
I remain unconvinced that denying access to the .ssh directory serves
any useful purpose, and regardless it is possible to do that by not
including the files within the user's jail.  The former should be well
understood by people who know OpenSSH well, and the latter just seems
obvious to me.

> while. Sadly, security is an area where you are typically unaware that 
> you erred on the lenient side until someone actually takes advantage of you.

True enough...  But that's exactly why I don't want command-line
parsing in rssh in the first place. ;-)

-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D


[Attachment #3 (application/pgp-signature)]
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
rssh-discuss mailing list
rssh-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rssh-discuss


[prev in list] [next in list] [prev in thread] [next in thread]