On Sat, Jun 10, 2000 at 01:20:06AM +0200, JF Martinez wrote:
> This applies if upgrading individually. If I upgrade my entire
> distribution the warning will be lost somewhere in the install.log.
> Yes _I_ check but can you ensure all RedHat's customers check?
I can't. The problem is that you simply CANNOT replace good administrative
practices by dumbing down the software.
>
> When a system can be afforded only by organizations
> having 2000+ employees that means that the organization can afford to
> have an employee who spends the whole day reading HOWTOs and manpages.
> Now in a five person organization the system administrator has to do a
> thing called _real_ work and that means that he cannot spend days
> reading HOWTOs so he will not know about the problem in the first
> place.
THIS is truly scary. If you're proposing that, for any sized
organization-- or even a single person, if they're using their machine
for anything other than casual recreation--the administrators don't
need to consider studying part of their _real_ work, you're setting up
a disaster. Period.
ANY operating system/network--be it Unix/Linux, Windows NT,
Netware--is, of a necessity, more complicated than can be administered
correctly "by guess and by golly". ANY person who takes on the role of
administrator is GOING to have to study the system and read
documentation--be it manuals, HOWTOs, or taking cert courses. Micro$oft
has low-balled this (e.g., its "ZAK" approach) and it's one of the reasons
that Mickeysoft systems are usually peanuts to crack--you've a lot of
> Now as I said everything you do as root is a potential security risk
> so the less you do as root the better...
This is undeniably true.
> And mail (ie data sent by strangers) can be a potential vehicle for
> attacks
No. The mail is just data. A stupid MUA is the vehicle for attacks--so
don't use one with that 'capability'.
> so as you don't want to be at the mercy of a flakey MUA you
> should alias root.
This is not something I necessarily agree with. The difference in our
positions is this: You don't use any tool as root that you can't trust.
If there's a possibility that any MUA _can_ do something stupid with your
mail, DON'T USE IT.
> But the guy
> who works in a small organization could be the target of an attack the
> day before reaching the page of the book where he is told how to alias
> root and why he should do it. That is why the MTA should not accept
> to deliver to root: root has no business reading mail
I'll argue that the guy working in ANY organization, and planning to
put any sort of system up for exposure to the big, bad world, had
da*n-well BETTER have read the whole book before opening the door. If
people are going to be actively stupid, there's only so much a vendor
can do.
A theme you and I firmly agree on: Systems that are provided by
vendors should be configured with the most reliable, sensible security
as the default. That's something RedHat and other Unix/Linux vendors
have always had a problem achieving; there's a difficult balance
between usability and security.
And performance and usability--the stock RedHat kernel is loaded for
bear, because they don't know what sort of hardware they're going to
encounter on first installation. You should always reconfigure and
rebuild your kernel once you're on the destination system.
In the same way, you should always review the system and security
configuration as-shipped on any system and tune it. You should troll
the newsgroups, vendor mail support archives, and vendor documentation
for known problems, complaints, suggestions, etc. BEFORE putting the
machine in production--hell, even before installation.
All this is just part of the _real_ work of administrators.
> Ah! if I remeber well Outlook was not inherently unsecure according to
> MS: it only allowed people to hang themselves.
According to MS. The biggest problems with M$ are:
-They don't *understand* security.
-They want to convince their users that running an operating system
doesn't require study or understanding, even a networked multi-user
multi-tasking system.
-They categorically configure for usability over security, since
security gets in the way of whiz-bang bell'n'whistle features (like
automatically running attachments).
-THEY DON'T TELL US EVERYTHING. Their documentation is
fragmentary, incomplete, proprietary, and difficult to find. They
have a vested interest in SELLING documentation--their
Certification programs. There is information that you can't
(officially) have from M$ unless you pay them to take their
courses. This is criminal...offer the courses for those who want
to get the information presented in an orderly manner, sure; but
if you're selling the system, you should provide all the
information necessary to work with it as part of the system...
SO, with Outlook, the information to secure it is scattered,
incomplete, and in some cases not available. I don't CARE if some
weenie at M$ has the information on his/her desk--it's useless to me if
I can't have it.
Cheers,
---
Dave Ihnat
[EMAIL PROTECTED]
--
To unsubscribe:
mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
