Reco wrote:
> Bob Proulx wrote:
> > Most of those systems ship very little by their vendors.  I have used
> > them for many years and almost all of the software that you will use
> > on those systems will have been compiled and installed by the local
> > admin.  IMNHO they are mainly a good solid base upon which you as the
> > local admin build the working system upon.  And for me if we are
> > talking about what we compile locally from source I would need to look
> > but the list is several hundred packages long!
> 
> Oh. You mean that HP suddenly transformed to good fairies and stopped
> charging extra for aCC? Or IBM received an encrypted signal from their
> supervisors from Mars and did the same to vacc? And don't even mention
> Sun, those guys managed to build their base system with two different C
> compilers at once (gcc and that thing they put in Sun Studio instead
> of C compiler).

Wait.  You mean the first thing you compile on a new system isn't gcc?
Sometimes it would be 'make' first.  Then gcc, binutils, and the rest
of the support chain.  The make again using gcc.  Then a hundred
others!

> As for 'solid base'... C'mon, treating openssh as a third-party tool? No
> meaningful firewall in default install? Telnet and FTP (root is allowed
> by default) enabled by default and are listening 0.0.0.0? Mandatory
> access control as a paid feature? Clearly our definitions of 'solid
> base' are different.

By solid base I mean the Unix kernel.  Have you ever needed to rescue
a system suffering under a fork-bomb?  Under the Linux kernel with
defaults you will need to power cycle it.  Even if you were already
logged into it at best you would rather quickly get "Connection closed
by foreign host."  But I have been able to log into HP-UX systems
while under such stress and was able to kill the offending processes.
That is what I meant by a solid base.  It has a solid kernel.  That is
the base of the operating system.  The other things you mention I
place in another layer above it.  Most are policy decisions about
telnet, ftp, and others wide open you can affect and change when it is
your system to maintain.  There isn't any reason not to turn off
telnet and ftp entirely for example.

But I agree about the security aspect.  When I have needed to put one
of those legacy systems on the net I usually protected it by putting
it behind a separate firewall box.  Because of some of the problems
you mention.  Using a separate proxy box for just the task needed made
the security easier.  But that doesn't make the machine less reliable
for running large loads with an uptime of years.

And one must be careful of throwing stones.  For example Debian does
not provide a firewall by default.  And it is debatable if it needs
one.  Many people don't configure one.  Many people do.  It all
depends upon many things about the use case.  I don't put one on
internal machines.  But I do put one on front facing machines.

> > You left the large "unless local sysadmins care about security" escape
> > clause there.  But what about if the local admin *does* care about
> > security?  In that case you can have a system with _better_ security
> > than that provided by the vendor.
> 
> If local sysadmin cares about security then that site is truly blessed.
> No irony. See, I earn my salary for solving problems with certain
> proprietary cross-platform software. As a part of job, I visit may
> different places, and what do I see there?

No need to try to convince me.  I have seen many horrors.  But I don't
think this problem is specific to the legacy Unix vendors.

> Outdated (like, 10 years outdated) SSH clients. Passwords stored in a
> plain text files in a recyclebin (or on a sheet of paper under the
> keyboard). Telnet as a primary administration tool (because 'terminal
> looks funny in a SecureCRT if I use SSH'). Cargo cult as the main
> method of configuring servers. Advices such as 'disable encryption in
> SSH, our server's CPUs cannot handle encryption' (copying files with
> scp from one Superdome to another). Complete inability to grasp even
> basic concepts of TCP/IP (we have network guys, they handle it).
> 'We're using VLANs so we don't need to encrypt anything'. 'We've
> installed antivirus everywhere = we're secure'.
> And last, but not least - 'security is complex, security bores me,
> security breaks our system'.

Yep.  I agree totally with what you have said.  I have seen the like
myself up close and personal.  Horrors!

> And they are not Joe and Jane the Average End Users. They are
> sysadmins :(

Yes.  But just because they have the job does not make make them good
at it.  Most importantly it does not give them the attitude that if it
is broken then it must be fixed.  (Broken windows lead to more
brokenness.)  The attitude is more important.  If they are persistent
then with the attitude that broken windows must be fixed then they
will learn what they need.  Attitude is more important.  But too often
I see people who simply occupy hours on the time card.  If they don't
have someone pushing for them to fix something then nothing happens.

> Not that UNIXes are that bad. It happens for any OS, GNU/Linux included.

And that is exactly my point.  The biggest place I see problems today
are companies that have full paid support for RHEL.  But they are
running very old and outdated software.  I ask them why they are
running RHEL and the answer is invariably because that was a
commercially supported platform for them.  Then I ask them if they are
actually getting support.  The answer is invariably no, but that is
the way "corporate" set them up.

For one they never actually hook up to the RHN.  Usually because they
are behind proxy servers and just never knew how to do it.  And so
even though they are paying for support they don't actually get it.
Because it is a commercial vendor.  By contrast if they were using
Debian, or CentOS for their equivalent free(dom) replacement for RHEL,
then they would have easy software security upgrades available to them
and could be fully up to date.  Because RHEL is so popular with
corporations I see a very large number of fully paid for licensed
systems that are in practice very unsupported systems.  Oh the irony!

> > And even in the case of an overworked and somewhat slack admin the
> > system security with source sudo installed but old is probably about
> > the same as the provided by the vendor.  Vendors don't update their
> > software that often and usually not without something pushing them to
> > do so.
> 
> Sudo had vulnerabilities that lead to gaining root access by exploiting
> them. And people will use is as vendors won't provide them any
> meaninful way to update all installed software at once.
> Therefore - using outdated sudo is an equivalent to wearing
> T-shirt with a root password written on it as an end result will be the
> same.

That is an exaggeration.  For one it would need to be a local exploit
for sudo to come in play.  Therefore it would require a local user to
attack it.  A local access attack.  The password on a t-shirt would
require simply require someone who could walk by the admin and see it
to gain remote access.

Most of the users on such machines are all working for the same
company.  The first person to break into the machine probably is doing
so in order to fix something while the official admin is not
available.  Or not knowledgeable enough.  Everyone in the group will
know it and it won't be a concern.  And very likely that person will
very soon be nominated into becoming the next officially designated
admin for the machine!  Been there.  Done that. :-)

> > For improved security a system with many eyes upon the code such as
> > Debian is much better.  Anyone using a traditional legacy Unix system
> > today is most likely not using it for the security of the system but
> > for other aspects of it.
> 
> That's true, but. I didn't implied that proprietary software is
> insecure (although, honestly, it is :) given what kind of people
> actually writing it today) a priori, I meant that using outdated tool
> for gaining security actually lowers it.

I agree with you that those machines are hard to argue as being
secure.  Especially today.  Most vendors have outsourced their deep
maintenance three shell companies deep overseas.  Things happen but
not with any real understanding.  Bugs don't get fixed anymore.  They
don't even get documented anymore.  It isn't a happy ecosystem.

But when they are being used today they are mostly buried deep behind
layers of networking.  They are not available for attack from the
outside world.  The inside world is all working for them and they
don't need the protection from them.  The reliability of the kernel is
more important.  They actually could operate without a root password
and it won't be a problem.  And I mean that seriously.  Therefore I
can't get excited about an outdated sudo on an old Unix system.

Bob

Attachment: signature.asc
Description: Digital signature

Reply via email to