Results 1 to 22 of 22
  1. #1
    Join Date
    Aug 2002
    Posts
    149

    Locking user in home dir in SSH

    How do I do this? If the user cd .. he can get out of his directory. He can read all files.

  2. #2
    Join Date
    Mar 2002
    Posts
    1,003
    Set up other directories so the world(others) can't read them.

  3. #3
    Join Date
    Jun 2000
    Location
    Washington, USA
    Posts
    5,991
    chmod 711 /home

    and chmod 711 /home/<user dir>

    It'll atlest keep them from doing an ls on the directory.

  4. #4
    Join Date
    Aug 2002
    Posts
    149
    /home ?
    Is that the dir structure you use? I'm using /var/www/home

    I hope it isn't a security risk. Well, I guess I'll try and disable the list in home.

    I can't believe SSH doesn't come with a command to unable the user from leaving base dir.

  5. #5
    Join Date
    Aug 2002
    Location
    in Europe
    Posts
    19
    There is the possibility of using a restricted shell like rbash.
    Check out http://www.gnu.org/manual/bash-2.05a...ashref_75.html .

    And you need to take additional steps to secure that shell,
    such as providing a custom $PATH , with a limited number of
    applications available etc.

    BTW. you may "accidentally" cripple that shell account so
    much, that no-one will want it .

  6. #6
    Join Date
    May 2001
    Posts
    1,513
    Wouldn't jailing the users by using chroot or SAFE.pm on all accounts work?

  7. #7
    Join Date
    Aug 2002
    Posts
    149
    Explain (I'm a newb)

  8. #8
    Originally posted by chrisb
    Wouldn't jailing the users by using chroot or SAFE.pm on all accounts work?
    In theory this would work. But you have to consider that all of the binaries are located outside their home directory, so it's a little bit more involved than just chrooting their shell to their home directory upon login.
    Matt Lightner - http://www.mattlightner.com/
    - First initial to the last name at the mail service provided by the world's largest search engine
    - Founder and CEO (Former) Site5.com, sold in 2008
    - Really honestly wants to be a good WHT citizen but can never remember all the correct etiquette. Mods, sorry in advance

  9. #9
    Jailing users and trying to only provide them with what they'll want or need (or what you're willing to give) will work to a point, but it can be circumvented anyway. Not to mention other things like PHP and CGI that will just bypass a shell jail anyway. The best way to accomplish the task of protecting users files is to simply use proper ownership and permission, as well as what user certain services run as.

    That will ultimately affect how things are secure from other users and should be the important factor. Provided you practice that logic, you will have no need for jailing users (even if chrooting services might protect them better, users are another issue and there are better ways to accomplish it).
    Robert McGregor
    URL: http://www.2host.com
    Email: robertm@(nospam)2host.com

  10. #10
    Join Date
    May 2001
    Posts
    1,513
    Sounds like Robert knows more about this than I, so permissions are the best way. Does anyone disagree with that?

    If permissions are the best way, do you also need to set the sticky bit on the directories?

  11. #11
    Join Date
    Aug 2002
    Posts
    149
    Say I only really want to protect one data directory from the user, how would I do that? I tried disabling LIST to Others of the directory but then Apache reads it as a 403. If I only disable READ to Others Apache can't list the files can still access them with pico. If I disable READ of the files I get 403s in Apache.

  12. #12
    Originally posted by chrisb
    Sounds like Robert knows more about this than I, so permissions are the best way. Does anyone disagree with that?

    If permissions are the best way, do you also need to set the sticky bit on the directories?
    To be clear, I meant that a combination of permissions and ownership's are the key element here. There are only certain things a client needs to access. In shell, they access programs that will only (or should only) affect them and for their user. For email and FTP, etc., that is already not an issue. So you are left with web access and such things.

    Web access involves a few things; httpd (along with SSI, any directives, mime types, action, etc. that they can perhaps add via .htaccess (and you can specific what directives a user can add to have more control and prevent problems while allowing them to have whatever they will want or need)), CGI, PHP. httpd itself is partly a problem, but not too bad. CGI can run with a CGI wrapper.

    So you have PHP that then is about the only interactive aspect that needs to access the user's directories/files to serve up web content. Without PHP as a module, you can easily set the server up to keep users out of other users file completely, set limits on processes via the web server (you already have limits set for disk quota, process, cpu, memory, cpu time, process limits, open file limits, etc. for shell), and you have a controlled, safe server (in that regard).

    However you enter PHP as a web server module and it changes some things. I won't get into all of that and I'm going to try and develop a solution for that shortly, but for the most part, it's simple to use a combination of ownership and permissions to solve almost all the problems associated with users being able to access, use, modify, etc. other users files. You can see where jailing won't help, and even if (or unless) you run a web server for each account, you would still have this problem unless you applied some simple permission and ownership settings. Provided they are correct, a jailed user is no more secure than a non jailed one (plus you save disk space and other issues from being a problem). The explanation is more in-depth than this, but the logic is simple.
    Robert McGregor
    URL: http://www.2host.com
    Email: robertm@(nospam)2host.com

  13. #13
    Originally posted by anile8
    Say I only really want to protect one data directory from the user, how would I do that? I tried disabling LIST to Others of the directory but then Apache reads it as a 403. If I only disable READ to Others Apache can't list the files can still access them with pico. If I disable READ of the files I get 403s in Apache.
    Apache runs as the group "other" and so do all of the "other" users that aren't in your user or group. You can try a combination of group settings and deny everyone from that directory, but don't add Apache's user or group to it. However, a user that can run a non SuEXEC'ed CGI or a non-CGI PHP with the SuEXEC wrapper can still just have their script just read the directory contents and anything else Apache needs to access.

    You will need to use a wrapper to fully protect it (i.e., CGI or PHP as CGI with SuEXEC or some similar wrapper method) so you can set the permissions low enough to where only your user can access it, and Apache will only access it after having the process go through the wrapper (which means that no one else's web server process (global or not) can access the directory or files within it).
    Robert McGregor
    URL: http://www.2host.com
    Email: robertm@(nospam)2host.com

  14. #14
    Join Date
    Aug 2002
    Posts
    149
    Isn't there a way to deny only a specific user access to a directory and all sub-dirs and files? That way other users (such as apache) could still access it.

  15. #15
    Originally posted by anile8
    Isn't there a way to deny only a specific user access to a directory and all sub-dirs and files? That way other users (such as apache) could still access it.
    If you're root or ask your hosting provider, yes. Just set the group ownership to that users' group and set the group permission to 0. They can still access it via SSI, CGI or PHP, etc. though.
    Robert McGregor
    URL: http://www.2host.com
    Email: robertm@(nospam)2host.com

  16. #16
    Join Date
    May 2001
    Posts
    1,513
    Originally posted by anile8
    Isn't there a way to deny only a specific user access to a directory and all sub-dirs and files? That way other users (such as apache) could still access it.
    You might look at the <LIMIT> and <DENY> directives in apache. Someone correct me if I'm wrong. I'm still learning this stuff myself.

  17. #17
    Join Date
    Aug 2002
    Posts
    149
    Hehe, I tried that just before reading your post. Great, it works. I can just apply base dir restrictions in PHP can I not?

  18. #18
    Join Date
    May 2001
    Posts
    1,513
    Originally posted by anile8
    Hehe, I tried that just before reading your post. Great, it works. I can just apply base dir restrictions in PHP can I not?
    Since you didn't quote... what worked?

  19. #19
    Join Date
    May 2001
    Posts
    1,513
    Originally posted by anile8
    I can't believe SSH doesn't come with a command to unable the user from leaving base dir.
    I can't believe this either. IMO, it should.

  20. #20
    Join Date
    Aug 2002
    Posts
    149
    Hehe, not before reading your post. Before reading 2host's post.

  21. #21
    Originally posted by chrisb


    You might look at the <LIMIT> and <DENY> directives in apache. Someone correct me if I'm wrong. I'm still learning this stuff myself.

    That will only deny people from web access, not shell.
    Robert McGregor
    URL: http://www.2host.com
    Email: robertm@(nospam)2host.com

  22. #22
    Join Date
    Jul 2002
    Location
    Philadelphia, PA
    Posts
    15
    Checkout:
    http://chrootssh.sourceforge.net/

    You will need to have all the binaries the user will require in a bin directory and a library directory under their home-directory. I suggest putting on every home partition, a copy of the contents of /usr/bin, /lib, and /usr/lib.. then make hard-links into everyone's home directory. Just make sure that the permissions of those files are proper... for additional security, have a separate copy of those binaries and libraries in each user's home directory..

    I'm more paranoid then you are

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •