[nycbug-talk] fave BSD tips/tricks?

[Jerry B. Altzman]

on 8/25/2009 1:00 PM Miles Nordin said the following:
>>>>>> "jba" == Jerry B Altzman <jbaltz at 3phasecomputing.com> writes:
>    jba> Clearly, your idea of what 'basic unix' things are and mine
>    jba> differ.
> mine's based on what used to be included on Unix systems.  ex., xcalc
> is part of the base X11 distribution and used to always be there,

OK, well, someone took it off.

> while on overmodularized Gentoo I don't get it unless I ask for it.  I
> get systems that have tar but are missing pax and cpio, systems that
> don't have tcsh because, durrrrr, guess the sysadmin doesn't use tcsh!
> I don't either, but leaving it out used to break most passwd files.
> Likewise, emacs is an extremely basic tool expected on any serious
> Unix system because well over half of wizards use it.  It's like some
> kind of revolution of the dropouts that emacs isn't expected any
> more---clicky certified sysadmins don't use emacs so ``times have
> changed''?  We don't have to install it because nano-using idiots are
> the ones doing the menial work of installing the systems that the
> wizards have to use, at least what few wizards are left.  ``works for
> me so fuck off'' is a Windows attitude.

Yes, but "you don't need it on a production server" is not.
Leaving out tcsh from a server and having it break password files is 
bad. Leaving out emacs is a matter of taste at the very worst -- I don't 
include it in on production servers, because, well, people aren't 
supposed to be doing heavy-lifting editing there.

> Internet-exposed software listening on sockets makes your system a
> bigger target, as does more kernel code, more network protocols
> (IPv6), and more setuid binaries.

No argument there.

> xcalc, not so much.  It's just plain wrong.  Deleting stuff like this

Sez you. "Just plain wrong." Feh.
I don't want xcalc on my public-facing servers.

> does jackall for your securitah.  Installing things on the disk that
> the attacker could just upload anyway doesn't make any difference!  It

Why leave the tools around? I don't get it. It's not security through 
obscurity, it makes your machine that much harder to compromise through 
silly stupid stuff. I don't leave knives in the baby's playpen, either.

> may set off your security buzzer a little more often, because

When you have more than one machine to manage, having a quieter security 
buzzer means more sleep at night.

Your mileage may vary.

> vulnerabilities like ``reading a malformed message with mutt could
> execute arbitrary code in the user context'' won't go BRRK-BRRK if you
> don't install mutt, but removing mutt doesn't give you any more
> security than not using mutt.  Do I really need to explain the unix

Yes, but if I have more than one user on my machine, just because *I* 
don't use mutt doesn't mean someone *ELSE* won't.

You want it both ways here: you want all the things YOU think are useful 
and castigate people who remove Miles's Expected Packages, and yet you 
forget here that you might have other users on the machine who might use 
tools that you don't!

If <x> isn't installed, then none of the other sysadmins on my team will 
inadvertently use <x> to do something stupid.

> security model?  It seems blatently obvious to me, yet I see MOST
> people operating under these silly wrong assumptions.

Which part of the security model? Least privilege? Don't leave sharp 
tools around?

Or maybe "security in depth"?

I'm not into the whole Tootsie Pop ("hard and crunchy on the outside, 
soft and chewy on the inside") security model.

>    jba> We had a hard and fast rule about not even having
>    jba> compilers available on production servers: why give possible
>    jba> miscreants more tools to play with?
> see above.

Why make it *EASIER*? If someone gets on the box as an unprivileged 
user, but they have to spend hours getting gcc on there to compile their 
rootkits, it's that much more time I have to respond to the incoming threat.

> Or learn how to actually break into a machine, compete in a CTF game
> or something.

Been there done that. So what?
When talking about development servers, sure, have everything you want.
When talking about production servers, no, have the barest minimum. Lock 
it down tight.

> yeah, doing nonsense like this may actually help you in CTF, but only
> because it's a time-based spy-vs-spy game.  Annoying yourself to annoy
> the attacker without actually doing anything concrete to stop him is
> dumb.  unless you really think that you are the only one who can

Yah, well, I guess everyone's entitled to your opinion.  It doesn't 
annoy my trained staff to expect very little on my production servers.

> figure out how to compile programs somewhere else and/or install a
> compiler when one isn't there, and the attacker can't manage it, which
> seems preposterous since the attacker will have more skill than a
> sysadmin of this kind.

So...the alternative is...what?
I don't get it.
If I have an extra hour, then that's an extra HOUR I have to prevent or 
mitigate damage.
At what cost? The cost of not having gcc or xcalc on my *production* 
servers? Why do I want someone running unnecessary processes there?
Seems like a minor inconvenience for a stronger security model.

//jbaltz
-- 
jerry b. altzman  jbaltz at 3phasecomputing.com  +1 718 763 7405