Hello, i am setting up a shell provider here on Linode... i have seen other shell hosts that dont allow certain programs, even if u compile them yourself. i really would like to know this, plus other info such as restricting them access by users/etc....

i am using debian linux here.

ty

No offense, but if these questions are not questions you can answer yourself, then I highly suggest not setting up a shell provider. (I'll openly admit, I'm *HIGHLY* against public shell providers)

I'm not going to deny it, I don't know how to answer these questions. Though I can offer a few suggestions:

First, you may want to look into pam_chroot. The sources need to be grabbed from ftp.kernel.org (unless your distro comes with pam_chroot packages, which is doubtful). The sample config file it comes with is pretty helpful

Secondly, you may want to remove the execute perm on many directories. What this does is it allows a user to read any and all files from whatever directory, but *ONLY* if they already know about them. By removing the exec perm users cannot list the contents of a directory. (This sounds pretty useless, but I've seen it used in an interesting fashion with various Solaris setups and with Mandrake's Msec tool)

You may wish to limit the outgoing connections they can make. Additionally what ports they can open that are accessible from the outside world. I know that iptables can allow some control via groups (basic TCP/ACL support? I dunno)

As for preventing users from running code they compiled themselves. I wasn't aware this was possible. Assuming one creates statically linked libraries with their own headers, I would assume it would be rather hard to prevent them from running their own code. You could restrict their access to various /dev files .... but I supposed that would have undesired effects.

Bill Clinton

mount /home with the "noexec" option. make similar provisions for any other directory to which users may write files (i.e. /tmp).

If you want to stop users from compiling+executing arbitrary programs, mount the home directories noexec.

Of course, you'll also need to do that to every partition containing a directory that's writable by your users. This includes /tmp, /usr/tmp (if different from /tmp), and anywhere else that your distro defines. Make sure that your distro works with a noexec /tmp; it may break stuff. Debian in particular doesn't work with /tmp mounted noexec; I forget why, but Google knows.

Don't forget to chmod -x /lib/ld-linux.*, otherwise a malicious user could just run /lib/ld-linux.so.2 /home/mallory/a.out.evil and sidestep the noexec option.

Also, you'll need to make sure your users don't have access to perl, python, or any other interpreter that allows access to the filesystem or the network.

Then, you've got to install programs that are exploit-free. If a user finds (e.g.) an exploitable buffer overflow in some random utility, they can use that to run arbitrary code.

Basically, unless you only allow your users to run cp, ls, rm, and the like, a user with enough time and patience can run anything he likes despite your best efforts.

Though I support your right to do what you want with your linode I have to question your judgement in setting up shells on it. Any attack against your shell service or clients will be impacting other people on the shared host who, unlike a dedicated shell hosting provider, did not choose to be on a server with shell accounts. I guess thats something to keep in mind when considering UML hosting.

_________________
www.fxpbackup.com

Thinking about this a bit more, I've come up with something that might be useful. It won't work on a Linode, though, since you can't have a custom kernel.

If you were to take a system with all the measures suggested so far in this thread, and put on a custom kernel with a noexec stack patch (Ingo Molnar maintains one for 2.4 and 2.6 kernels), and maybe a few other security patches, then you might be able to avoid most of the local exploits.

For the filesystem, use quotas and locked-down permissions to keep your users in line.

Restricting network access is a bit trickier. If you assume that there aren't any local exploits, then what you can do is only allow certain executables to have network access. A process's process table entry will tell you what the name of the currently running program is (like /usr/bin/nmap). What I would do is write a wrapper around sys_socketcall to place some restrictions on the programs that can make that system call, based on the program name. If you only allow programs that can't easily be made to misbehave, you're probably in good shape.

Of course, there's lots of little details here that I'm glossing over, like that you probably only want to restrict socket calls for AF_INET sockets, since local sockets are really useful in IPC, etc.

Sorry to rain on your parade, but setting up a secure server that any random person can have shell access on is just plain hard.

Honestly without a GRsecurity type kernel patch and disabling compiler access etc theres no way it will be secure. Theres just too many chroot break out scripts out there that take 0 knowledge to run. You just don't give shell access out to anyone you don't know and trust these days. For every known exploit theres probably 4 more that weren't part of the "full disclosure" movement. If you want to offer bouncers you would be better off setting up the bouncer yourself and adding people access accounts to it rather than giving them shell access. Theres just a certain level of financial cost where you can't do IRC related business - at the cost level of UML you will get every 12 yr old kid with an allowance and a paypal account. - on that note I have a question for Chris - are there controls in place to prevent shell account hosting from draining the resources and bandwidth of the machine? What kind of DOS protection is in place and possible on a UML server? If one account gets attacked can I kiss my development project goodbye because I'm on the same machine? I think given the nature of UML the "neighbors" have a right to know these things.

_________________
www.fxpbackup.com

thx for all of the great replies, but to sign up you must talk to me on IRC to interview the person. i think i will sieve out all the lamers...

-k3rnel

like everyone else has said . . . it's not a good idea . to give out free shells.

I would not just use irc to interview people . . . . people are very good at not telling the truth.

I am all for the idea of free Shells . . . but people are stupid and can't handle something like that.

Do you realize that you are putting your neck on the line? As a consultant to a state computer crimes task force, I can tell you that if any illegal activity is committed on your linode, YOU will be served with a subpoena. What are you going to do when you cannot provide the valid name and address of your 'user' in response to the subpoena? Why do you think Linode goes through great lengths to verify our identities before activating our accounts? In addition you may incur civil liability, especially if a victim feels you did not take adequate measures. "Interviewing" people over IRC will not cut it. Like any service provider to protect yourself you need to use an accepted method to verify identities (most use credit card billing address), have some sort of contract/AUP in place, and have the whole operation checked out by a qualified attorney. Without such practices in place, you will be attracting people who have a reason to hide. Linode will be able to quicky wash their hands of any wrong doing on your linode, will you?

Trust all the advise you are getting on this forum -- offering free shells is a recipe for disaster.

I suppose you might be the prefect person to ask this OT question ...

Does the above hold true for people who provide free wifi ?

Bill Clinton

Rumour has it that FOONet was raided by the FBI for hackers using one of thier boxes. Its not too far off to assume that this could happen handing out shells to people on IRC..

http://easynetworknyc.com/foonet/

wow thats crazy

In answer to the wifi question.... It's a great question. On the criminal side, it's doubtful any free wifi provider would ever be served with a subpeona or search warrant under the former conditions simply because there is no evidence to collect. As opposed to someone offering free shell access where there is tons of potential evidence that would be very much worth an investigator's time pursuing. The only exception I can think of is if a suspect under investigation frequents a particular wifi network, a search warrant could be obtained to install a packet logging system.

It's really interesting to do a Google Groups search on foonet. Most of the traffic will be found in news.admin.net-abuse.email - not a good sign.

_________________
Bus error (passengers dumped)