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