Results 1 to 15 of 15
  1. #1
    Join Date
    Apr 2004
    Posts
    111

    dont allow shell bash users to execure binaries

    Is it possible to not allow shell bash users to execure binaries? how. Is it possible to not allow executing selected commands? Is it possible to not allow acces outside home dir?

    And I answer here questions that would be asked here few moments after posting. (please restrain yourself from going off topic, and debating).

    Q: Perhaps your're looking for a way to disable bash
    A: No

    Q: Then perhaps you're just want to make webpanel executing only selected bash commands?
    A: No

    Q: Then why let ppl use shell/bash if they cant execute binnaries
    A: shell isint really only for running programs! It provides with tousands of commands for operating on ascii files, copresion, decopresssion and also can provide with ssh secure file transfer, far better look into your files etc etc
    Last edited by nand; 07-07-2005 at 09:29 AM.

  2. #2
    Join Date
    Jun 2003
    Posts
    961
    you might want to take a look at chrooted/jailed environments

  3. #3
    Join Date
    Mar 2003
    Location
    California USA
    Posts
    13,294
    "A: shell isint really only for running programs! It provides with tousands of commands for operating on ascii files, copresion, decopresssion and also can provide with ssh secure file transfer, far better look into your files etc etc"

    those commands are all binarys
    Steven Ciaburri | Industry's Best Server Management - Rack911.com
    Software Auditing - 400+ Vulnerabilities Found - Quote @ https://www.RACK911Labs.com
    Fully Managed Dedicated Servers (Las Vegas, New York City, & Amsterdam) (AS62710)
    FreeBSD & Linux Server Management, Security Auditing, Server Optimization, PCI Compliance

  4. #4
    You can permit to run particular progams on behalf of any particular user vith sudo.

  5. #5
    Join Date
    Apr 2002
    Posts
    86
    You will need to chroot them into a directory tree with the noexec flag set.

  6. #6
    Join Date
    Apr 2004
    Posts
    111
    Originally posted by classics
    You will need to chroot them into a directory tree with the noexec flag set.
    noexec flag? how to do this? I seen tutorials how to mount partion with noexec flag

  7. #7
    change the permission for normally accessing binaries like wget , tar , zip , gunzip , lynx , etc to 700 . this will prevent normal users from accessing these binaries.
    Choose the right option ... The world is open for You..

  8. #8
    Join Date
    Apr 2004
    Posts
    111
    they can always have own binaries.

  9. #9
    Join Date
    Jul 2005
    Location
    Beverly Hills, CA.
    Posts
    242
    Look into LES from Rfxnetwork. I can do what you are looking for I think.

  10. #10
    Join Date
    Jul 2005
    Posts
    62

    Re: dont allow shell bash users to execure binaries

    Originally posted by nand
    Is it possible to not allow shell bash users to execure binaries? how. Is it possible to not allow executing selected commands? Is it possible to not allow acces outside home dir?

    And I answer here questions that would be asked here few moments after posting. (please restrain yourself from going off topic, and debating).

    Q: Perhaps your're looking for a way to disable bash
    A: No

    Q: Then perhaps you're just want to make webpanel executing only selected bash commands?
    A: No

    Q: Then why let ppl use shell/bash if they cant execute binnaries
    A: shell isint really only for running programs! It provides with tousands of commands for operating on ascii files, copresion, decopresssion and also can provide with ssh secure file transfer, far better look into your files etc etc
    This is my first response to a post here, figured I'd pick a good one =) I've got about eight years on the server side of the hosting industry under my belt.

    You need to take a multi-pronged approach at doing what it is I think you want to do. Just to make sure I understand, you want to allow customers access to a system shell, Bash in this case, but limit what they can do.

    You could mount a partition noexec, but if your web content is stored on the same partition as the user's home directories, you could run into some pretty harsh CGI problems. Doing something like this is going to hurt.

    The next logical approach would be to remove the world execute bit from all of the commonly used system binaries that can be used for malicious purposes, i.e. wget, rpcinfo, showmount, and so on. The downside to this approach is that it's very superficial. Users can still easily upload their own binaries.

    As a matter of fact, look at the problem from a higher point of view, forget about binaries. Users have access to an entire C library of system calls. Even if you decide you don't want to give them shell access in an effort to protect yourself from this, nothing is stopping them from writing their own code and launching shell commands (or standard library calls) programatically. They can do everything in a CGI script that they can do from a command line.

    The standard chroot() approach is nice, but it doesn't stop malicious users from running DDOS bots, et al.

    What you really need to do is protect yourself at a bit of a higher level. You have administrative access to the system, your customers do not. Instead of limiting their functionality (all your really doing by disabling these things is annoying them), you want to limit their ability to do harm to the system. Here is what I'd recommend.

    1. Disable outbound traffic on all ports except those needed to run your system. For example, let your system contact name servers, ensure that it can connect to ecommerce processing systems, but an arbitrary user does not need to be connecting to a remote web server on port 7612. Don't let anyone use YOUR machine for attacks. I can't count the number of IRC bots I've seen on shared servers. This is OS agnostic. Use IPFW, IPTables, or your vendor equivalent. If they can't play, they have no reason to try.

    2. Exactly what type of server are you maintaining? There are "vendor" specific lock-down approaches you can take. Statistics say you're probably running a Linux based system. Take a look at SEL, or Security Enhanced Linux. You can read about it (message me for URL, I haven't posted five times yet). Setting limits here on certain things you want to rule out can easily help protect you.

    3. Resource limits, resource limits, resource limits. The other reason to limit shell access is to keep users from doing resource intensive things on your hosting machine, such as large compilations. Use your native Unix resource limits. If they start using too much memory, CPU, disk, or run too many processes, they'll simply encounter an error.

    Now you've protected three key areas. Your users can't attack other users. They can't do anything you don't want them to do, and they can't overwhelm a system accidentally by doing stupid things. They can, however, enjoy a feature-rich shell environment and get their work done without restriction.

    Also - throw up tripwire or something if you're going to allow shell access. It won't hurt, and in the event of a problem, you'll know.

    Hope that helped!

  11. #11
    Join Date
    Sep 2002
    Location
    Top Secret
    Posts
    11,687
    You're not going to be able to get individuals to buy into this kind of an environment, not in the realistic hosting world.

    Why? Todays hosting involves MUCH more than silly html web pages. users want to be able to actually ADD something, make their content dynamic. They want usability, NOT security to the extreme that they can do nothing.

    Example:
    Users want galleries of pictures. With crap like suexec, limiting (as you would suggest) individuals from accessing binaries, you won't get that. What you'll get is a ton of errors from whatever process, because those galleries require (for the most part) images to be converted, and in order to do THAT properly, well, you need to access system binaries, such as convert, and packages such as ImageMagick.

    Example 2:
    User needs a perl script. Well, guess what, without the proper permissions, or the ability to call perl (properly), what you get is essentially a screwed up user.

    Example 3:
    Apache starts as a NON root user (usually nobody). I guess you don't want to run a webserver, do you?

    I could go on and on, but I do believe I've made the point.

    The true solution to this problem is NOT to run a limited server which will kill every user, and ruin your chances of success, but to do things properly. KNOW what's going on with your server, listen to what it's saying to you (because, believe it or not, it is talking), react to what's going on in a professional and timely manner.

    If you don't know anything about administrating a server, hire an admin. Hey, it'll save you a bundle the first time someone comes up with an advanced problem, and the first time you have to deal with a "hack".

    Eventually, you're going to be hacked. The question isn't IF, but what and when. What are you going to do about it. When will you be notified? When the DC tells you? Or when your server tells you. Hopefully, it'll be the second, because the first will be WAY too late!
    WHMCS Guru - WHMCS addons, management, support and more.
    WHMCS Notifications Extended - Add slack, hipchat, SMS, pushover to WHMCS !!
    Always looking for Linux, WHMCS, Support Desk work. PM for details

  12. #12
    Join Date
    Jul 2005
    Posts
    62
    Originally posted by linux-tech
    You're not going to be able to get individuals to buy into this kind of an environment, not in the realistic hosting world.

    Why? Todays hosting involves MUCH more than silly html web pages. users want to be able to actually ADD something, make their content dynamic. They want usability, NOT security to the extreme that they can do nothing.

    Example:
    Users want galleries of pictures. With crap like suexec, limiting (as you would suggest) individuals from accessing binaries, you won't get that. What you'll get is a ton of errors from whatever process, because those galleries require (for the most part) images to be converted, and in order to do THAT properly, well, you need to access system binaries, such as convert, and packages such as ImageMagick.

    Example 2:
    User needs a perl script. Well, guess what, without the proper permissions, or the ability to call perl (properly), what you get is essentially a screwed up user.

    Example 3:
    Apache starts as a NON root user (usually nobody). I guess you don't want to run a webserver, do you?

    I could go on and on, but I do believe I've made the point.

    The true solution to this problem is NOT to run a limited server which will kill every user, and ruin your chances of success, but to do things properly. KNOW what's going on with your server, listen to what it's saying to you (because, believe it or not, it is talking), react to what's going on in a professional and timely manner.

    If you don't know anything about administrating a server, hire an admin. Hey, it'll save you a bundle the first time someone comes up with an advanced problem, and the first time you have to deal with a "hack".

    Eventually, you're going to be hacked. The question isn't IF, but what and when. What are you going to do about it. When will you be notified? When the DC tells you? Or when your server tells you. Hopefully, it'll be the second, because the first will be WAY too late!
    ...or worse yet, when your customers tell you.

    Using the Apache suExec wrapper in a true virtual hosted environment actually *buys* you a lot of functionality, and if done properly, it can reduce the number of permissions related support tickets you'll have. Not using suExec requires you run all of your CGI applications as whichever user the web server is running as. In turn, any content you want editable by CGI applications must be editable by that user. Nine times out of ten, you wind up with a server that has 500 users on it, all with a 'cgi-bin' directory that's owned by 'nobody', or at the very least, editable by that user. In such a scenario, user A's CGI scripts can go right ahead and mess with user B's files.

    With suExec, all of your customer's files will be editable by said customer and the number of "how do I set permissions" calls will go down. It is a bit tricky in terms of FrontPage, PHP, et al... but it can be done. In a well configured environment, I've seen suExec be *very* useful.
    Last edited by McJeff215; 07-09-2005 at 12:42 AM.

  13. #13
    Join Date
    Jan 2005
    Location
    Chicago
    Posts
    226

    Re: dont allow shell bash users to execure binaries

    Originally posted by nand
    [B]Is it possible to not allow shell bash users to execure binaries? how. Is it possible to not allow executing selected commands? Is it possible to not allow acces outside home dir?
    yes and yes. use bash in restricted mode. find bash docs.

    copy bash to a file called 'rbash' and set that as the shell to invoke restricted mode. seriously.

    you'll need to set the user environment up in a crafty way to do what you need, but yes it can be done and does work.
    Ken

    CROWHOST hosting+colocation services | 877-CROWHOST | support at crowhost.com
    Independent remote-hands serving all Chicago data centers

  14. #14
    Join Date
    Jul 2005
    Posts
    62
    The problem with restricting bash is that you can't change directories and it kills shell redirection. Using it is again simply going to annoy users. It is another option, though.

    I think your best option is to leave the shell alone - give people a workable environment - and secure the system itself. Like linux-tech said, know what's going on as opposed to hiding one way of executing commands.

  15. #15
    Join Date
    Apr 2003
    Location
    NC
    Posts
    3,080
    Look at grsecurity or lids, both are kernel level patches and support the type of thing you are looking at. Lids is a really interesting project and will take some work getting it all configured but once you have it should work great.
    John W, CISSP, C|EH
    MS Information Security and Assurance
    ITEagleEye.com - Server Administration and Security
    Yawig.com - Managed VPS and Dedicated Servers with VIP Service

Posting Permissions

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