The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

I don\'t want telnet/SSH users to snoop on the HD and into o

Discussion in 'General Discussion' started by Domenico, Sep 4, 2001.

  1. Domenico

    Domenico Well-Known Member

    Joined:
    Aug 14, 2001
    Messages:
    362
    Likes Received:
    0
    Trophy Points:
    16
    Hello,

    Can any of you cpanel developers tell me (and all the others) how I can prevent users when telnetting from snooping around others peoples dirs and server directories?

    I really do hop Nocsoft deals with this MAJOR problem but please can you tell me in the meantime how to handle this in a manner that CPANEL will keep on working?

    Yes, I allready chmod /home to 711 but that hardly solves a thing.

    THANK YOU!
    Domenico


    btw. A nice thread about this issue is here: http://www.webhostingtalk.com/showthread.php?s=899326e9519df0d1b36ab04869b6c199&threadid=7847&perpage=20&pagenumber=1 but I don\'t think that the solution written there will work on a CPANEL server
     
  2. zex

    zex Well-Known Member

    Joined:
    Aug 12, 2001
    Messages:
    98
    Likes Received:
    0
    Trophy Points:
    6
    cPanel Access Level:
    Root Administrator
    Well basicly it\'s hard to prevent other users from snooping into other ppl dir, BUT
    you can use some special things like kernel patches that i\'m using to stop ppl from viewing other processes except one that they own. Also kernel patches offers solution for your problem but it\'s not so clean as you may expect... They add special chmod\'s for users that are in special group (untrust) and you can track all execv and fork\'s command so you will basicly now what\'s happening and who is snooping around.
    Since i\'m intresting for making real solution for this problem (even if that includes writing new kernel patches) you can contact me on e-mail about this problem with details.
    :)
     
  3. kosmo

    kosmo Well-Known Member

    Joined:
    Aug 12, 2001
    Messages:
    403
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    All over Europe
    I did following:

    chown username.nobody /home/userdir/
    chmod 773 /home/userdir/

    Now, user username and apache (group nobody) can read, write, execute, and everybody else write and execute but not read (mysql passwords and other config stuff).

    I don\'t know how good this is but it looks to me like working.

    kosmo
     
  4. Domenico

    Domenico Well-Known Member

    Joined:
    Aug 14, 2001
    Messages:
    362
    Likes Received:
    0
    Trophy Points:
    16
    yeah, but you have to do this for every user I suppose?
    What if I said I have 3000 users? I don\'t have that many but this is hardly a solution I think. Thanks anyway for your input.

    [quote:fd17543d30]I did following:

    chown username.nobody /home/userdir/
    chmod 773 /home/userdir/

    Now, user username and apache (group nobody) can read, write, execute, and everybody else write and execute but not read (mysql passwords and other config stuff).

    I don\'t know how good this is but it looks to me like working.

    kosmo [/quote:fd17543d30]
     
  5. Kiwi

    Kiwi Well-Known Member

    Joined:
    Aug 11, 2001
    Messages:
    75
    Likes Received:
    0
    Trophy Points:
    6
    Another solution would be an option from WHM to not allow resellers to set-up accounts with SSH. Except yourself as the root user.

    Like ...the SSH option in the account creation form would automatically be unchecked and not be allowed to be checked.
     
  6. Gadget

    Gadget Member

    Joined:
    Sep 4, 2001
    Messages:
    20
    Likes Received:
    0
    Trophy Points:
    1
    [quote:e88e5cc7ea]I did following:

    chown username.nobody /home/userdir/
    chmod 773 /home/userdir/

    Now, user username and apache (group nobody) can read, write, execute, and everybody else write and execute but not read (mysql passwords and other config stuff).

    I don\'t know how good this is but it looks to me like working.

    kosmo [/quote:e88e5cc7ea]

    Since all of your users files are now owned by group nobody and that group now have full read write and exe permissions when you chmod 773, any user can put a script up that can rewrite anyones site on the server. Scripts not in the scgi-bin also run as user nobody so any and every user on your server can now destroy the other users sites.

    someone correct me if im wrong
     
  7. company name

    company name Registered

    Joined:
    Sep 3, 2001
    Messages:
    2
    Likes Received:
    0
    Trophy Points:
    1
    Um, if you set the /home/username directory to 773 and set the ownership to user.nobody, then you have opened up a big problem. That thread on webhosting talk that you referred to, didn\'t say to set those permissions. Why would you give Apache\'s user world readable, writeable access? It only needs execute access on the /home/username directory (being 5), or you can try (1) for Apache to work. Anything else, you are allowing Apache\'s processes (PHP and CGI scripts) to have the same permissions on that user\'s parent directory that the user themselves have. This is a very, very bad idea! Set it to 753 (why do you even have the world have 3, btw? That\'s not needed... You don\'t need to allow world access anymore, if you allow the user and Apache itself access via the user and group). The only reason why you give world execute permissions (5), is for Apache to access that directory and you can set it to 1, which is better anyway. So, 710 or 750 would better solve your problem and not give Apache itself as much access on the user\'s home directory as the user themselves has. ALSO, look into something that\'s known as \"stick bit\" (i.e., 0777 and 1777 are two different things). Finally, to change the group and permissions of all user\'s dir\'s, even if there is 3,000 user\'s just do a chgrp nobody /home/* and chmod 750 /home/* Simple, isn\'t it? Be careful with what people are talking about in this regard, as you cn make some big mistakes if you don\'t fully understand what they mean or the principals of it. Good luck!
     
  8. Brownie

    Brownie Well-Known Member

    Joined:
    Aug 10, 2001
    Messages:
    145
    Likes Received:
    0
    Trophy Points:
    16
    [quote:089b7a596b][quote:089b7a596b]I did following:

    chown username.nobody /home/userdir/
    chmod 773 /home/userdir/

    Now, user username and apache (group nobody) can read, write, execute, and everybody else write and execute but not read (mysql passwords and other config stuff).

    I don\'t know how good this is but it looks to me like working.

    kosmo [/quote:089b7a596b]

    Since all of your users files are now owned by group nobody and that group now have full read write and exe permissions when you chmod 773, any user can put a script up that can rewrite anyones site on the server. Scripts not in the scgi-bin also run as user nobody so any and every user on your server can now destroy the other users sites.

    someone correct me if im wrong [/quote:089b7a596b]

    Files are owned by user.user
     
  9. kosmo

    kosmo Well-Known Member

    Joined:
    Aug 12, 2001
    Messages:
    403
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    All over Europe
    Thanks \"company name\". You make my life much easier.

    kosmo
     
  10. perlchild

    perlchild Well-Known Member

    Joined:
    Sep 1, 2002
    Messages:
    279
    Likes Received:
    0
    Trophy Points:
    16
    A better solution

    A better solution would be to chroot each ssh connection, except the one you use as root. Would allow greater control over who sees what.
    ==modified from original post==
    Just to clarify chrooting would make the user's home appear to be / with everything above that being invisible. So users wouldn't see each other's contents. Careful thought usually needs to be applied to provide binaries in a chroot environment(which directories? for what purpose), I know of a case of binaries being in /usr/local/dbapp/bin causing havok to such a chroot setup, as it wasn't planned for it
     
Loading...

Share This Page