JF Martinez wrote:
> I know it but there will be people who don't know about it, forget
> it or perhaps one day a person at RedHat makes a mistake and my alias
> file is overwritten with a vanilla one where root is not aliased.
You _do_ have regular backups, don't you?
> Everything you do as root who is not strictly needed for
> administration is a potential security risk be it using the Gimp,
> using gcc, or reading mail.
That's only partially true. The fact of the matter is that mail _will_
go to root, and there's nothing wrong with that fact _per se_. I do
NOT want someone else coding their idea of security into tools that I
know perfectly well how to secure myself with today's toolset. One
Micro$oft is enough, thank you.
If you don't want mail to go to root, forward all root E-mail to an
unprivileged account. If you know you're using a MUA that doesn't
interpret attachments, like pine, elm, or mutt, then go ahead and let
it go to root. Your choice as a sysadmin.
> Since we cannot exclude the eventuality of
> a defective MUA or one with a trojan then an MTA should not accept to
> deliver to root. No alias, no delivery.
No, No, NO. The MTA is NOT supposed to be overloaded with this junk. It
should be an MTA. Your MUA, or security software, or whatever, worries about
that.
Furthermore, you can NEVER exclude any of the above--they're red herrings in
this discussion. The only question you have to ask yourself is: Does your
MUA ever, _ever_ blindly execute attachments? If so, then THAT MUA must not
be _used_ by a root-privileged user.
> Point. Guns have safetys so you don't shoot yourself in the foot,
> software should have safetys too.
But the safety goes on the gun, not the spotting scope. Put the safety on
the MUA.
By the way, it's funny you used that analogy. One of my favorite quotes--
somewhat paraphrased due to time and relativistic effects--goes "Unix not
only doesn't prevent you from shooting yourself in the foot; it offers you
a range of calibres."
> BTW sendmail was designed in a time was designed when the few who used
> the Internet were adult, equilibrated people so it was czertainly not
> built for being secure.
Hoo, hah, *snort*, chuckle, *sigh*. Wipe my eyes. Believe me--I was there.
You've gotta be kidding; "adult", "equilibriated" (interesting word, that.)
We were no different than today--some were responsible, mature people who'd
never use corporate or academic resources for anything unsanctioned. Some
wrote and played nethack. (I still miss my dog.)
Sendmail evolved--designed is probably too strong a word--when the
first goal was to figure out what we _meant_ by E-mail and what the
problems were in handling it. It shows--the configuration language is
so arcane that, even after using it for 20+ years, I need to go back to
notes. Your comment about security is correct not in that it wasn't
considered; but rather, it wasn't the first priority. Before E-mail
security can be a big problem, you have to be able to deliver E-mail.
> Today there are many people in the Internet
> and some of them re not adult, are half crazy or are dishonest.
Some days, I'd say you're being too kind... More appropriately, the
numbers haven't changed. Rather, more people have _access_ to the
'Net. And the vast majority of the problems aren't dishonesty; most
stem from adolescent irresponsibility and one-upmanship. (Won't stop
me from throwing 'em in jail when I catch them, though.)
> And we cannot afford allowing inherntly insecure features like allowing
> mail delivery to root.
No; we cannot afford quick-fix solutions that don't properly address the
problems within the framework of the Unix/Linux philosophy. Provide the
means for educated administrators to handle the problem. Ship systems with
default configurations that make sense. Stop writing code with buffer
overruns--this is just sloppy programming!!! Stop enabling, by default,
"features" in tools that expose the user to security vulnerabilities.
But always remember--you still have to offer that range of calibres for
those of us who know gun safety.
Cheers,
--
Dave Ihnat
[EMAIL PROTECTED]
--
To unsubscribe:
mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
