Operating Systems > Linux and UNIX

Linux Kernel Security. forkbomb havoc

<< < (3/8) > >>

muzzy:
I was going through other threads to find what I'm referencing to, but there's just too much text to read through it all again. I see that you're saying in another thread it's the administrator's job to keep the system secure. Some other people were bitching about how it's unfair that I compare properly configured (and thus, administrated) windows to a linux system.

I'm getting a little tired of arguing with multiple people without remembering whose stance was exactly what. You all seem to have different opinions, yet you all argue with me and not amongst each others.

Anyway, the rc scripts differ from system to system, and there's no rc.local in every system. Even then, you aren't guaranteed secure because services you run might set the hard limits up again... There are kernel patches which provide better solutions, but again, these would need to be applied.

Also, putting too much responsibility on the administrator is just screwed. If the vendor doesn't fix security holes, is it the admin's responsibility to write binary patches? Well, obviously nobody else is going to do it, but whose responsibility is it really? If you're taking the stance that it indeed is administrator's responsibility to keep the thing secure, no matter what, then we're back to square one regarding my stance on windows and its security.

Calum:

--- Quote from: muzzy ---I was going through other threads to find what I'm referencing to, but there's just too much text to read through it all again. I see that you're saying in another thread it's the administrator's job to keep the system secure. Some other people were bitching about how it's unfair that I compare properly configured (and thus, administrated) windows to a linux system.
--- End quote ---
yes X11 said this (ak! sorry, he is now called kintaro on this board), and to a point he was correct. if you want to do tests to compare one with the other, it's meaningless unless the things you are comparing are on a level field. comparing two systems that are administered properly, using the tools available to the administrator is fair, and comparing two systems brand new, as is, out of the box is also fair, so long as in both situations, people know what the comparison is. comparing one system that is administered well by somebody who knows the system with another system that is badly administered for any reason is not fair, and the results are meaningless.


--- Quote ---I'm getting a little tired of arguing with multiple people without remembering whose stance was exactly what. You all seem to have different opinions, yet you all argue with me and not amongst each others.
--- End quote ---
this sounds pretty paranoid, and in fact it is untrue. there is more than one member i have had recent disagreements with, though you might not be too lucky finding them since they haven't been all in one thread, or nearly so public facing as the "get rid of shit in windows" thread, or whatever it was called. people will have differing opinions, and if you can't remember who said something, don't just claim that the nearest respondent had those opinions which are contrary to your own. perhaps this assumption leads  you to believe that people are always against you here? the fact is i think most people consider you to be knowledgeable and fairly understandable (which is pretty good for these boards!)


--- Quote ---Anyway, the rc scripts differ from system to system, and there's no rc.local in every system.
--- End quote ---
yes this is true. i think now that i have looked a little on my home system, that on an LSB compliant system, the right file to modify would be /etc/init.d/boot.local (but correct me if i am wrong folks!) since this script gets executed on any LSB compliant system before we enter our default runlevel or allow anybody to log in.
--- Quote ---Even then, you aren't guaranteed secure because services you run might set the hard limits up again...
--- End quote ---
well of course you can just set those hard limits in that file, can't you? or have i missed something here about who is allowed to do what?
--- Quote ---There are kernel patches which provide better solutions, but again, these would need to be applied.
--- End quote ---
yup, or accepted into the actual kernel source. i have no idea what the situation is with this or if these solutions are indeed better than ulimit, or what the arguments are, so i can't comment at all here.


--- Quote ---Also, putting too much responsibility on the administrator is just screwed. If the vendor doesn't fix security holes, is it the admin's responsibility to write binary patches?
--- End quote ---
ok, i see your point, there's a line to be drawn, and you reckon setting a reasonable ulimit value falls on the vendor side of the line, while i don't agree. fair enough. i would say that anything that can be done in readable config files or using a GUI that comes with the system, should be the admin's responsibility and anything else is the vendor's. how's that? not all vendors agree. like the whole RHN thing. if i install red hat, the first  thing i do is remove that, because i want to use apt to do my own software upgrades/installs, but red hat doesn't give you the option not to install it at install time, because it assumes that it's red hat's responsibility to have rhn warn you to upgrade things.
--- Quote ---Well, obviously nobody else is going to do it, but whose responsibility is it really? If you're taking the stance that it indeed is administrator's responsibility to keep the thing secure, no matter what, then we're back to square one regarding my stance on windows and its security.
--- End quote ---

yep, i think i mention where i would personally draw the line above, but you're kind of suggesting a model where there's a problem and *no* solution, whereas usually with the open source stuff i find that if a problem arises there are usually *several* solutions, and this is something people complain about too sometimes. remember when people moaned that linux had no native journaling filesystem? very quickly several appeared, ext3, jfs, xfs, reiserfs and so on. some distros chose different ones to use as default, and as a result the default filesystem for one linux might not be supported by default, by another linux system. This is the downside of choice, if you are given a choice (as a system administrator, user. or software distributor), you have to make a choice, and people will make different choices. this can be seen as a good or bad thing depending on what your priorities are.

muzzy:
Privileged processes can set hard limits to anything they want, unprivileged and only lower their hard limit. This is why ulimit in /etc/profile works for loginshells in the first place. The user can limit the shell, but not unlimit. Same isn't true for privileged processes, see setrlimit(2) manpage for the implementation of the resource limits. What I'm saying, is theoretically apache or cron or whatever daemon could just set the limits back to some horribly large one, and then processes spawned by it would inherit those values. You just couldn't be sure.

Further, setting the limits for init, even if it works, doesn't solve the problem. The user can still bring down the system, and as long as the forkbomb process lives nobody else can make new processes. I don't have a linux box to test this behaviour, but either this happens or it isn't effective in the first place. The system will remain responsive, but as no new processes can be spawned, it's pretty much useless.

Many kernel patches indeed provide better solutions, such as per-user accounting for all the process resources. This way the user wont be able to escape hard limits, since they're enforced by the kernel and per-uid. I believe grsec does this, for example.

muzzy:
What comes to having choices, it's indeed both good and bad. The real problem is that most casual users (who have been forced to be administrators, by having a computer at home) won't have enough knowledge to make informed decisions. For this reason, it's a good thing that the vendor does the decisions for the administrators. For this reason, vendors should have responsibility for the security and performance and functionality of the system. Administrators these days just can't be expected to have enough arcane knowledge about internals of the system to be able to make good decisions. Otherwise you get people putting ulimits into rc scripts and login profiles... ;)

Calum:
i cannot agree with that last post on two counts.

firstly you more or less say that vendors are responsible for the security and stability of the systems they vend, because administrators are too dumb. with logic like this it is clear to see why you prefer windows over other OSs. no doubt using windows  and talking to windows users is what brings you to this conclusion in the first place.

secondly, once again you criticise potential solutions without yourself explaining the answer. by suggesting that people are idiots for suggesting the ulimit line be put in one script or another you are attempting to stifle discussion about this issue. also, you do not clarify where  the correct location for such a line might be, which is something you should be doing if you are so staunch about how wrong everybody else's solutions are.

Navigation

[0] Message Index

[#] Next page

[*] Previous page