Restricting my users

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

27 Replies

@k3rnel:

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…. 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 pamchroot. The sources need to be grabbed from ftp.kernel.org (unless your distro comes with pamchroot 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

@Bill Clinton:

@k3rnel:

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.

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.

@k3rnel:

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

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.

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.

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.

@jmeyers:

I can tell you that if any illegal activity is committed on your linode, YOU will be served with a subpoena.

[snip][snip]

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/

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.

@proane:

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..

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. :roll:

@Bill Clinton:

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.

Sorry for the late followup, but this is backwards. If you want people

to be able to access files only if they already know them, then you want to enable execute and disable read and right, e.g.

chmod 751 /some/dir

will allow users to access files in /some/dir but not list the contents of /some/dir..

Also, to k3rnel, let me reiterate what the others have said: it's almost impossible (with the standard Linux kernel, anyway) to provide useful functionality to arbitrary users and prevent a hostile users from executing arbitrary code.

I applaud anyone who's idea is to further Linux/Unix usage, and that's what offering shells is….furthering Linux, whether it be paid or free shells.

I know of at least one Linode member who is offering free shells and is doing a VERY good job of screening and admin'ing. Being proactive in monitoring usage and logs helps a LOT. Screening (as best you can) helps alot also. Not offering shells to people you don't physically know helps also. There are tons of ways to serve shells and yet be intelligent about who has access to those shells. If I had 30 sincere friends that wanted shell access to my box and I felt they were trustworthy, why shouldn't I offer them access when I know it wouldn't pose a security risk?

Associating free shells with insecurity is a niave thought, IMO.

Not offering free shells does NOT guarantee that you won't be cracked. Regardless of how you secure your box, there will always be ways a cracker could gain unauthorized access. No box is every 100% secure.

I'm a network security analyst by trade, working for Northrop Grumman. I've seen some interesting things. I'd worry about bad users on free shells least of all. Software with vulnerabilities that worms and such take advantage of is the story of the last year and a half. There will be risks to any given box in the world that's connected to the internet (and even boxes with no access to the net can still be cracked, if you're at the box's physical location and know a bit of social engineering).

ANY errant service on a linode will affect its neighboring linodes…a node with a service that's hogging resources isn't all that much different from cracker who's conducting activity that will hog resources. The only difference is perception…you won't even know its a cracker until it's found that it WAS a cracker that was responsible for the activity.

From what I saw of the TOS and AUP, it's not even mentioned, so I'm assuming its OK to offer shells on your linode. Just wondering why everyone is so concerned when his ideas aren't really violating any rules of usage.

@unixfool:

Associating free shells with insecurity is a niave thought, IMO.

Not offering free shells does NOT guarantee that you won't be cracked. Regardless of how you secure your box, there will always be ways a cracker could gain unauthorized access. No box is every 100% secure.

This is true. Locked down boxes can be cracked and many public shell providers have never been hacked. However, allowing people local access on your system greatly increases your chances of having your Linode compromised. Many exploits require local access to the system. Furthermore it sounds like the original poster lacked a thorough knowledge that it takes to tightly secure one's Linode. I think the combination of these two features would add up to spell "rooted" very quickly.

@milo:

@unixfool:

Associating free shells with insecurity is a niave thought, IMO.

Not offering free shells does NOT guarantee that you won't be cracked. Regardless of how you secure your box, there will always be ways a cracker could gain unauthorized access. No box is every 100% secure.

This is true. Locked down boxes can be cracked and many public shell providers have never been hacked. However, allowing people local access on your system greatly increases your chances of having your Linode compromised. Many exploits require local access to the system. Furthermore it sounds like the original poster lacked a thorough knowledge that it takes to tightly secure one's Linode. I think the combination of these two features would add up to spell "rooted" very quickly.

I dunno. I just tend to treat people as adults since he's obviously paid for his account and he's (big assumption here) read the TOS/AUP. I feel that as long as he hasn't violated any of the rules and since he has yet to have his linode compromised, then its a 100% total assumption, just an assumption, that his linode will be compromised, regardless of if he's coming across as lacking knowledged.

If and when something happens and I'm sharing a machine with him and lose data or bandwidth or resources, then I'll be upset, not before. If I myself became so concerned about what everyone else is running on their linode, worrying about how it would affect my own linode, I'd always be upset or paranoid….and I know if I knew what you guys WERE running, I'd probably be upset. I'd be paranoid that some 'neighbor' of mine would be running some vulnerable software package that would affect my share of the machine.

Basically, if I don't see caker worrying about people running IRC servers or shell accounts, I'm not going to worry about it either. I'm just wondering why so many people feel so strongly against this guy running a shell service instead of helping him be more knowledgeable about it, especially since offering shells isn't outlawed. I think I saw like 3 people that offered him good feedback.

@unixfool:

Basically, if I don't see caker worrying about people running IRC servers or shell accounts, I'm not going to worry about it either. I'm just wondering why so many people feel so strongly against this guy running a shell service instead of helping him be more knowledgeable about it, especially since offering shells isn't outlawed. I think I saw like 3 people that offered him good feedback.

Go back and read the thread again. Plenty of people gave him very good advice (I count 5 out of the original 8 or 9 posts that were very informative), but everyone came to the same undeniable conclusion: it's just much more risky than it is worth. It seemed like everyone was trying to save the original poster headaches as well as save us all the headache of dealing with a shared resource that has been compromised. I'm sure that if you asked the original poster if he felt that he got good advice in this thread, that he would say yes.

Obviously no one cares much what others run on their Linodes - there isn't even any real discussion on this topic on these boards. But most people recognize that as a shared resource it's to everyone's benefit to make sure that no one Linode hogs too many resources and causes problems. You can call it selfish if you want (which is what it sounds like you are trying to do) but it's not just in my personal interest that your Linode doesn't thrash the system and make Linode users unhappy - it's in your own as well, as you are likely to have a better and happier experience with your Linode if you're not subject to derision from other users for making their lives more difficult. Note that I'm not talking about you specifically, I'm talking about "you all" in general here.

@bji:

@unixfool:

Basically, if I don't see caker worrying about people running IRC servers or shell accounts, I'm not going to worry about it either. I'm just wondering why so many people feel so strongly against this guy running a shell service instead of helping him be more knowledgeable about it, especially since offering shells isn't outlawed. I think I saw like 3 people that offered him good feedback.

Go back and read the thread again. Plenty of people gave him very good advice (I count 5 out of the original 8 or 9 posts that were very informative), but everyone came to the same undeniable conclusion: it's just much more risky than it is worth. It seemed like everyone was trying to save the original poster headaches as well as save us all the headache of dealing with a shared resource that has been compromised. I'm sure that if you asked the original poster if he felt that he got good advice in this thread, that he would say yes.

Obviously no one cares much what others run on their Linodes - there isn't even any real discussion on this topic on these boards. But most people recognize that as a shared resource it's to everyone's benefit to make sure that no one Linode hogs too many resources and causes problems. You can call it selfish if you want (which is what it sounds like you are trying to do) but it's not just in my personal interest that your Linode doesn't thrash the system and make Linode users unhappy - it's in your own as well, as you are likely to have a better and happier experience with your Linode if you're not subject to derision from other users for making their lives more difficult. Note that I'm not talking about you specifically, I'm talking about "you all" in general here.

I went back and reread the thread…I still count only three people that offered original help. Another mentioned something that someone had mentioned already. That's a far cry from 5 out of 8.

I'm sorry if you thought I was calling it selfish. I wasn't. I do think it's a bit nosey though. While everyone should have SOME concern about what everyone else is running on their linode, that's about all it should be…a concern. Everything to do with hosting or services will involve shared resources, so I don't understand why the argument that we all have to be grossly concerned about some guy who wants to offer shells is valid. If I've a rogue process on my linode that involves an HTTP service, I'll be just as guilty as someone who's offered a shell on their linode to someone and that person is DOS'ing someone in China. Its just a matter of circumstances…in the end, both examples still amount to resource abuse.

And, as I've said, I already know of one linode person running a shell service. It could be a linode neighbor of anyone in here. You'll never know, unless their linode is hogging resources or some other bad indicator occurs.

I've yet to see the original poster offer further correspondence after his initial post. It seems as if he were run from the forums because what he wanted to do went against a perceived consensus. That's what I'm feeling, not what I'm accusing anyone of.

I'm 100% agreeing with the mentioned security concerns (its not something I'd do myself,on a linode), but I just feel that the responses to the original poster were….I dunno….heavy-handed?

Oh well, that's enough of this matter for me. I'm on to better things with my linode. :-)

There are a number of successful, mature, non-policy violating shell providers using Linodes, but I should say that in this particular case the user voluntarily left Linode.com's services, because he wanted to do "root-wars" with his buddies, thereby violating the AUP (basically the entire [System and Network Security] section).

So far, I haven't had problems with any of the other shell providers.

-Chris

Part of this is that the original poster didn't say he just wanted to offer shells. He wanted to offer shells and restrict his users to a subset of programs.

From the original post:

> i have seen other shell hosts that dont allow certain programs, even if u compile them yourself. i really would like to know this

This sounds like he wanted users to only be able to use programs from a whitelist. Most privileged programs are written with security in mind, but many unprivileged ones are not. Any security hole in any whitelisted program will let the users execute arbitrary code. Sure, it's executed with normal user privileges, but that still violates the security policy that the original poster had in mind.

Honestly, I'm not concerned with what other people do with their Linodes as long as it doesn't impact mine. My concern is with the feasibility of implementing this security policy on a Linode, or on any other machine for that matter. If there's a good way to do it without resorting to kernel modifications, I don't see it. (I hope it exists, but I don't see it.)

@caker:

There are a number of successful, mature, non-policy violating shell providers using Linodes, but I should say that in this particular case the user voluntarily left Linode.com's services, because he wanted to do "root-wars" with his buddies, thereby violating the AUP (basically the entire [System and Network Security] section).

Personally, I could care less what others do with their Linodes. The insulation that the host provides is getting better and better (see caker's post about the 2.6 kernel on the hosts). Even though I felt the odds of his Linode getting compromised were much higher than the rest of ours, I wasn't worried that someone would break out and then compromise the host. I was more concerned that the environment he was creating was ideal as an intermediate host for those who would launch attacks against others. Clearly, as confirmed by caker's last post, the the user was not prepared for offering shells as a robust, safe, and mature solution and thus was exposing himself to liability he was not prepared for.

@unixfool:

I went back and reread the thread…I still count only three people that offered original help. Another mentioned something that someone had mentioned already. That's a far cry from 5 out of 8.

OK, I'll count them for you. Here is a summary of the posts before your first post:

1. Original question

2. Helpful info from Bill Clinton

3. Helpful info from inkblot

4. Helpful info from smerritt

5. Discouragement from ne0shell

6. Helpful info from smerritt

7. Discouragement from ne0shell

8. Response from original poster

9. Discouragement from blahrus

10. Discouragement from jmeyers

11. Discussion from Bill Clinton

12. Discussion from proane

13. Discussion from blahrus

14. Discussion from jmeyers

15. Discussion from rjp

16. Helpful info from SteveG

The "Discussion" posts were discussion about the bad things which have happened to other people which have tried to do shell hosting, and I'm not going to call this discouragement because it really is helpful info, but I just won't count it at all.

So we have 10 posts which were directly addressing the question, and 5 of them were helpful. Make it 5 out of 10 then.

@unixfool:

I'm sorry if you thought I was calling it selfish. I wasn't. I do think it's a bit nosey though. While everyone should have SOME concern about what everyone else is running on their linode, that's about all it should be…a concern. Everything to do with hosting or services will involve shared resources, so I don't understand why the argument that we all have to be grossly concerned about some guy who wants to offer shells is valid. If I've a rogue process on my linode that involves an HTTP service, I'll be just as guilty as someone who's offered a shell on their linode to someone and that person is DOS'ing someone in China. Its just a matter of circumstances…in the end, both examples still amount to resource abuse.

The tone of your emails is kind of obvious to anyone who can read between the lines. You think that other people posting on these boards are being nosy or in some way out of line by trying to convince the original poster that it's not worth it. I didn't see anyone post anything in this thread other than concerns, which is exactly what you state people should have. Your posts themselves are "concerns" that other people are too "concerned". Except that when it's other people's concerns, you call them "grossly concerned". I'm not trying to berate you personally, I don't even know you and I am sure you are a nice and well-meaning person. But you're being hypocritical here, and I kind of resented your original implication that the other well-meaning posters to this thread were being too nosy or otherwise misbehaving by trying to give the guy equal amounts of information and discouragement from doing something that would likely have caused more trouble than it was worth, for him or for the rest of us. Nobody here is paid to help this guy out (except caker), and I think that people on these groups have gone way above and beyond the call of duty in trying to provide help wherever possible.

Even nice guys can sometimes get it wrong, and I'm just saying, you got it wrong.

@unixfool:

I've yet to see the original poster offer further correspondence after his initial post. It seems as if he were run from the forums because what he wanted to do went against a perceived consensus. That's what I'm feeling, not what I'm accusing anyone of.

I guess I didn't see that at all. He said "thanks for the great replies", and then said that he would talk to people on IRC directly before giving them free shells, presumably as his mechanism of weeding out the bad apples, and the discussion continued on after that. He never posted back, but I can hardly see where what people said drove him out.

@unixfool:

I'm 100% agreeing with the mentioned security concerns (its not something I'd do myself,on a linode), but I just feel that the responses to the original poster were….I dunno….heavy-handed?

But they weren't. They were good advice, both about the mechanics of how you would try to prevent users from abusing free shells, and restrict them to only certain executables (which is what the original poster wanted to know about), and about how unlikely this was to work well, and about how likely it was that his experience in trying to do so would be bad. All good stuff, from people who are not paid to help anyone but did so very well anway. I say good job everyone.

@bji:

OK, I'll count them for you. Here is a summary of the posts before your first post:

1. Original question

2. Helpful info from Bill Clinton

3. Helpful info from inkblot

4. Helpful info from smerritt

5. Discouragement from ne0shell

6. Helpful info from smerritt

7. Discouragement from ne0shell

8. Response from original poster

9. Discouragement from blahrus

10. Discouragement from jmeyers

11. Discussion from Bill Clinton

12. Discussion from proane

13. Discussion from blahrus

14. Discussion from jmeyers

15. Discussion from rjp

16. Helpful info from SteveG

The "Discussion" posts were discussion about the bad things which have happened to other people which have tried to do shell hosting, and I'm not going to call this discouragement because it really is helpful info, but I just won't count it at all.

So we have 10 posts which were directly addressing the question, and 5 of them were helpful. Make it 5 out of 10 then.

5 posts ago, I said I was finished with this, but it seems that someone won't let things go…

It's pretty obvious that your definition of help is quite different from mine, because after going back and checking your work, I'm still at a loss as to how some of what you considered help was actually help. After your analysis of the thread, I still only see 3 posts that offered help. Seems that all debating is highly subjective and in no way objective, which is actually wasting my time. That being said, the TONE of SOME of the posts seemed in no way supportive, IMO (IMO is heavily stressed). You're probably going to go back through every post and analyse every one of them and post how you think which one is help and which isn't…be my guest, but after this post, I'm done, so it'll probably be a wasted effort on your part.

> The tone of your emails is kind of obvious to anyone who can read between the lines. You think that other people posting on these boards are being nosy or in some way out of line by trying to convince the original poster that it's not worth it. I didn't see anyone post anything in this thread other than concerns, which is exactly what you state people should have. Your posts themselves are "concerns" that other people are too "concerned". Except that when it's other people's concerns, you call them "grossly concerned". I'm not trying to berate you personally, I don't even know you and I am sure you are a nice and well-meaning person. But you're being hypocritical here, and I kind of resented your original implication that the other well-meaning posters to this thread were being too nosy or otherwise misbehaving by trying to give the guy equal amounts of information and discouragement from doing something that would likely have caused more trouble than it was worth, for him or for the rest of us. Nobody here is paid to help this guy out (except caker), and I think that people on these groups have gone way above and beyond the call of duty in trying to provide help wherever possible.

I feel my concern is justified. Is it justified to be so concerned about someone else's linode that you basically suggest that he not run shell hosting? I feel, no. Is my concern of this thread justified? Uhmmm…IMO, yes. Why am I concerned of the tone of these posts? I'm new here. I've just purchased a linode for my personal use. I saw this thread and read the original poster's request. Let's put aside caker's comment, as that was information that all of us were not privy to until he posted. The original poster asked legit questions and his goals for his linode weren't even close to borderline TOS-breakers. It was ASSUMED, based on his post, that he wasn't knowledgeable enough to host shells on his linode and it almost seemed (to me) to turn into a witchhunt, by the tone of the responses to his posts. The responses weren't aggressive at all but I still perceived an overall feeling that this guy was leaned on a bit hard. We didn't know what he actually wanted to do until caker added his input as to what the original poster actually had in mind, so judging him was a bit immature. Even caker's post suggested that hosting shells wasn't out of the norm. Judging a guy's overall knowledge of Linux and Linux security based on one post is quite unfair, IMO, and it really rubbed me the wrong way. My thought was this: if the linode community were so concerned with this guy and his request, then what's to stop them from showing that same concern when I wanted to deploy some law-abiding service that went against the linode community's unspoken security concerns. If I'm a paying member and I'm breaking no terms, yet get heavily lectured about what or what I shouldn't be using on my PAID hosting….doesn't sound fair at all. If I were the original poster, I'd have considered requesting a refund and just found another provider (and keep in mind, still, that I'm keeping out caker's input about the original poster wanting something that wasn't acceptable by AUP…that knowledge wasn't available until just a few posts back, AFTER people expressed their views…the thread was winding down by then).

> Even nice guys can sometimes get it wrong, and I'm just saying, you got it wrong.

That's your opinion. Me, I wasn't even trying to be right or wrong. I've yet to blatantly accuse anyone of anything here. I'm just offering my perceptions and feelings. Actually, whether every poster here offered help or not, a majority of them DID offer concerns regarding security or performance hits on shared resources. That's what concerned me as a new user of a linode. As soon as I saw the post, I was concerned about having to watch my back for accusations about what I was doing with my linode. In fact, that's about all I've been concerned with. I'm frozen in my choices of using my linode because I don't want someone complaining because they think I've not deployed some server properly. That's my biggest concern as a new linode user since reading this post, but its just an opinion, and a highly subjective one at that…not based on any pure fact or such, just my feelings.

> I guess I didn't see that at all. He said "thanks for the great replies", and then said that he would talk to people on IRC directly before giving them free shells, presumably as his mechanism of weeding out the bad apples, and the discussion continued on after that. He never posted back, but I can hardly see where what people said drove him out.

Well, I can. I've already explained it above. Whether or not he actually felt that way, we'll never know. But if I were someone like caker who was offering a paid service and this happened, I'd be concerned of potential customers reading this, getting turned off, and looking elsewhere. Besides, I never said he was actually run off. I said: "It seems as if he were run from the forums because what he wanted to do went against a perceived consensus," which is at http://www.linode.com/forums/viewtopic.php?p=3301#3301

> But they weren't. They were good advice, both about the mechanics of how you would try to prevent users from abusing free shells, and restrict them to only certain executables (which is what the original poster wanted to know about), and about how unlikely this was to work well, and about how likely it was that his experience in trying to do so would be bad. All good stuff, from people who are not paid to help anyone but did so very well anway. I say good job everyone.

Yes, I saw the advice, but there was also alot of security concerns voiced, concerns that hinted that maybe he shouldn't host shells at all. Let me explain who I am and what I do. I'm no newbie to Linux or technology. I've been using Linux since 1997, starting with Slackware 3.3. I'm still no guru…no human is, yet I try to help anyway I can. I'm involved with sharing ideas and helping people via forums and IRC. I'm an established member of several IRC channels on irc.freenode.net. I've dedicated much of my time and server bandwidth hosting web pages that contain HowTos and FAQs on my own dime. I take time that could probably be better spent elsewhere to help those who ask for help with their Linux problems. I use Linux and Unix professionally. I can analyse raw dumped network traffic. I'm a IT security consultant. I work for Northrop Grumman. I've worked for other big tech companies and I've worked for a startup. To sum it up, again, I'm no newb to technology. I too saw help, but not all was help. Helping someone is to answer their asked question. Maybe a few helped TOO much by giving very opinionated and skewed info on their perceptions of hosting shells. As caker stated, "There are a number of successful, mature, non-policy violating shell providers using Linodes."

You said, "They were good advice, both about the mechanics of how you would try to prevent users from abusing free shells, and restrict them to only certain executables (which is what the original poster wanted to know about), and about how unlikely this was to work well, and about how likely it was that his experience in trying to do so would be bad." Well, letting him know how bad running a shell hosting service was bad, IMO, as there are successful shell providers using linodes. You may not have said his whole idea was bad, but others did. Again, that's just my opinion.

I thought I'd be able to drop all this a few posts up, but I was drawn back in by your comments. I've said in all my posts that all I post is my perceptions. I've singled no one out and actually haven't accused anyone of doing anything grossly offensive. Someone being worried about what I run on my piece of linode.com…that's a bit offensive. Is anyone worried about me running something I shouldn't or me hogging resources? Did anyone accuse me of that? NO. Do I have a general feeling that it could happen to me, maybe falsely, especially after reading and participating in this thread? YES. I felt I should voice that. I've a concern of your concerns. LOL…that sums it up, I guess.

Yeah, this is my last post on the issue. I felt I was baited to respond this time, as I felt I HAD to answer some statements and misunderstandings but this is truly it. My feeling stands that if caker doesn't bitch about it and I'm within the written limits of the AUP, I'm good. I'll not worry about what people may be concerned with, regarding my linode.

Regards,

unixfool

@unixfool:

5 posts ago, I said I was finished with this, but it seems that someone won't let things go…

Well in the spirit of letting things go then, let me just say that we disagree but both have good points. So we'll just have to agree to disagree.

Best wishes,

Bryan

I'm coming a little late to the party here, but this is one case where a grsec-patched kernel (http://www.grsecurity.org/) might be rather cool.

I'm in the process of playing with it on my non-Linode boxen, and it's a big security win. In its default state it helps with a lot of the common exploit methods - randomising address space and making stacks non-executable to help stop buffer overflows causing pain, that sort of thing. With some work analyzing what you're system is supposed to be doing, you can set it up so that only designated programs can run as network servers, access files in certain directories, only certain groups can make network connections at all, even to the point where no users can run executables from anywhere other than the approved system directories (/bin, /usr/bin et al.)

I've not no idea how nicely it plays with the UML patches, though. If there's interest, and if Chris is amenable, I could probably find some time to help build / test.

Regards,

Tim.

Reply

Please enter an answer
Tips:

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (https://www.google.com)

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct