Unix paranoid hippies

I love how inconsistently paranoid Unix people are. They won't include "." in the path or make ssh/scp commands which accept passwords as commandline arguments, and are so anal about these kind of things all the time, yet their cp, mv, etc. will so happily crush files without prompt by default.

Apples and oranges.
kthx next troll plz.

>>2
Not a troll but actual rant

>>1
Oh fuck off. I use cp, mv mostly in automated scrips. If I want fuckin comfirmation I can supply the parameters manually or define some alias. For example, I have copy, move and remove defined as aliases so that they ask for confirmation when used manually.

>>4
And I'm not saying it's a bad thing for cp and mv to do that... I'm saying it's a paranoid stupid thing to not include "." in the path or allow ssh and scp to read the password from parameters. Just like one knows what's he's doing when using cp (or one uses it mostly in scripts), one should know what he's doing when typing a password in the commandline (which would be understandable for scripts). At least they could add some ugly GNU style parameter like --use-password-pretty-please-lol-lol

>>1
My mv, rm, and possibly cp are aliased to include -i, also, I use zsh, so I get extra security from user errors from that (asking about rm -Rf etc.).

I am >>2
My point is that you compare a security precaution with a (lack of) safety precaution. Two different things. Perhaps not having "." in the path is paranoid. Perhaps allowing the user to kill his system with a single careless command is stupid. But these are two different things and comparing them is retarded.

>>7
In my language, security and safety are the same word. It's hard to differentiate them.

>>8
What do you speak, stupidBOL?

Security = not getting zomg haxed.
Safety = not being allowed to shoot yourself in the foot.

>>9
You're also wrong.

Safety is a part of security. Security = confidentialty, integrity, availability. Think about it.

>>10
No, you're a dumbass.
One of the unwritten requirements for any *nix based operating system is intelligence.  So, you are expected to not shoot yourself in the foot.  However, you will be exposed to external attackers, like any OS.  Thus it has security features, but not too many safety features.

Safety is NOT a part of security.  Safety is compensating for operator/administrator fuckups and unintentional actions.  Security is protecting assets from unauthorized users.

>>11
Of course it's part of security. If you can accidentally shoot yourself in the foot, isn't that a threat to integrity and availability? Hello?! Do you even know what integrity or availability are?

Fuck off and learn something about security before coming up with some stupid arbitrary definitions of your own. Even the most basic books on security preface with "security = confidentialty, integrity, availability".

Security is protecting assets from unauthorized users.

No, it's a lot more than that. I rest my case: you don't know what you're talking about.

>>12
Just because "security"="confidentiality" (learn to spell), "integrity", and "availability" doesn't mean that "safety" HAS to equal all those things, and even if it DID, it doesn't necessarily mean that "safety"="security" or that all security features should be or include safety features as well.  And, while "safety" features may increase some of the same attributes as "security" features, it doesn't make them synonymous.

Protecting the administrator from his/her own stupidity and protecting from external attacks are two different things and should be treated as such by those who develop any kind of software to increase the security and/or safety of a system.

And no, security *isn't* much more than that.  Keep your data, logs, files, etc. out of the hands of unauthorized users.  That's security.  Your unecessary complication of the notion of security makes me wonder if any system you maintain is truly secure at all.  I'm sure it's "safe."  You couldn't delete logs if you tried, I'm sure.

And no, security *isn't* much more than that.

Insisting otherwise doesn't make it true. Security is more than just confidentiality. What use is your data if it's inaccessible or corrupt? To put it in more concrete terms: are DoS attacks a security issue?

Your unecessary complication of the notion of security makes me wonder if any system you maintain is truly secure at all.

Your understanding of security is naive and simplistic. But don't take it from me: the concept you're derogating was developed by the security community at large. People who make their living keeping multi-million/billion/national-level security up? If anything, c/s/i is too simple as well, the NSA specifies c/s/i and also authentication and non-repudiation.

Who the fuck are you?

(learn to spell)

Oh, no, a typo. I guess this means your "unecessary" is fair game?

>>14
Bandwidth is a resource to be protected as is data.  You should also keep your bandwidth out of the hands of unauthorized users as well.  That falls under the definition of security per se.  Thus, DoS certainly is a security issue.

Security should be as simple as possible.  The less complex an undertaking is, the less possibility of error, etc.  By not bloating notions of security with notions of safety, resources can be more effectively allocated.  I'd rather have an administrator that knows what they are doing and is reliable and then spend money/resources on protecting from external attacks than having to spend money protecting my system from an administrator's fuck up.
.
Authentication/non-repudiation: these have to do with keeping resources away from unauthorized users and nothing more.  They enact safety as a side effect, but the primary task of these mechanisms is what I said, keep unauthorized users out.  Thanks for proving my point.

Bill Gates couldn't handle something "too simple", and we got Windows.  Real secure.

Bandwidth is a resource to be protected as is data... Thus, DoS certainly is a security issue.

Yes, but why? You don't need any bandwidth if you're not accessing something, right? We need bandwidth to access our data.

Security should be as simple as possible.

Yep!

By not bloating notions of security with notions of safety, resources can be more effectively allocated.

I don't know about that. You'd be surprised just how far security stretches. For example, KISS systems with low coupling, careful design, and plenty of unit and integration tests can be trusted more (formal proofs even better), but technically that's an area of software engineering. Yet it's still a security issue.

Security is both a process and a mindset. Anything that threatens c/i/a is suspect. Some things are impossible to achieve ("Oh, shit, did I just delete that?!"), but you can make them both hard and recoverable.

we got Windows.

As much as I'm ragging on *nix here, it's one of the more trustable popular systems out there. It'll probably never approach some of the more secure VMS variants (RIP), but it's shitloads better than anything by Microsoft.