Re: ssh - chrooting

["Kristian Erik Hermansen" <user=152@nabble.blu.org>]

 Other than going through a chroot ssh howto with you, how about 
restricting what the remote users can do by using AppArmor?  You can 
whitelist everything you want the binary to do... 



On 4/30/08, Mark Richards <[hidden email]> wrote: 
> This is probably basic, but I have done my RTFM work for the day and 
> cannot seem to get past this one. 
> 
> We use dropbear client on some remote machines (running very automated 
> stuff).  We run ssh on our server and do NOT allow telnet logins (port 
> 23) nor do we support password authentication per se.  This closes, in 
> our view, some commonly exploited security worries. 
> 
> Each remote site has a unique RSA certificate and a home directory. 
> Each remote site uses dbclient as the transport where dbclient is used 
> by scp for getting and putting files in specific subdirectories off the 
> home directory on the server. 
> 
> By sheer accident (testing by initiating a shell using dbclient) I 
> discovered that I could cd /... cd /var/.. etc.  In some cases I could 
> even read and write files!!! 
> 
> Not what we had intended.  Now we have n number of sites out there, all 
> having nice keys into the production server where some hack can do who 
> knows what. Scary part is we don't know what the impacts may be, yet. 
> 
> My (stupid?) assumption was that a given user logging in via ssh would 
> be limited to their /home directory.  Not so.  Apparently any user 
> coming in via an ssh certificate assigned to a specific user can still 
> grope around, and if files/(directories) have world access, they can play. 
> 
> We tried a little trick: rc in the user's home/.ssh directory, containing: 
> 
> /usr/sbin/chroot . 
> 
> However it appears chroot cannot be executed by other than.. root! 
> 
> So, long-winded, but how might we accomplish the following: 
> 
> 1. Limit users to their home directory only 
> 2. Allow users enough access so they can perform scp operations in their 
> home directory and subdirectories off of it, and 
> 3. Allow users to delete a file (after an scp get).  This last one seems 
> like it's suited for a shell operation but since the remotes are 
> automated, it might be impossible. 
> 
> Any unix/linux file system folks out there care to chime in?  Public 
> whipping will be tolerated in order that we learn :) 
> 
> 
> 
> -- 
> This message has been scanned for viruses and 
> dangerous content by MailScanner, and is 
> believed to be clean. 
> 
> _______________________________________________ 
> Discuss mailing list 
> [hidden email] 
> http://lists.blu.org/mailman/listinfo/discuss
>