Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU |
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 >
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |