[NCLUG] Why not Root?

[John L. Bass]

Hi James,

Sure ... no problem. There are a few traditional AT&T UNIX derivative
systems that are fundamentally secure by design (and/or hardened by years
of proactive development in hostile educational deployments). There are
also a few BSD systems that are similarly hardened.

For the most part, nearly every major Linux distribution is nearly swiss
cheese in respect to security, because of the lack of a security centric
architecture review over it's components which are provided adhoc from
the linux and Open Source community. The other open source extreme, is
OpenBSD, where specific peer security review and audits are a fundamental
part of the project execution AND goals.

While most Linux Distro's fair pretty well security wise from outside remote
attacks, with some cleanup and attention to the services which are enabled,
none of the major distro's are secure out of the box with a hostile user
community or user imported trojans (AKA the windows spyware type attacks).
As I've noted already, a normal user's resources are more than capable of
supporting the typical trojan bots found on most compromised windows machines.

It would be nearly impossible at this point to secure major Linux distro's
like Fedora, as they are full of extremely poor security choices, specifically
running Pearl, Php, and Ruby scripting systems, plus many large binary systems
and dynamically loaded libraries as SUSER. All of these common systems are
individually adhoc maintained, with easy user hooks to providing extensibility.
It's relatively easy for user-kit compromises to exploit these to install
root-kit exploits when you have normal users performing SUSER admin functions
with well known back doors like su, sudo, and user accessable SUSER functions
provided by Gnome and KDE plug-in helpers, as well as distro provided admin
scripts.

But ignoring that, there has never been a rigorous security review and
redesign of critical security components, as new features are implemented
which render the assumed existing security models of existing tools and
subsystems moot. I'll provide at least one major example of this in a few
days that will suprise this readership, plus I've already referenced several
places where this creates problems with the assumed security architecture.

There is an assumption of internal security in the Linux community, but in
practice it's largely a myth at this point. It's going to take a number of
discussions (some of which are likely to be very heated) to raise awareness
to a level that this lax internal security trend is reversed.

World wide the "Security Community" is fractured, and not well self defined.
There are a few tens of thousands "security experts" that can quote a significant
subset of the Cert Advisories, and know the details of many major exploits. Many
of those are IT staff, security hobbiests, and script kiddies. For the most
part, they can talk the talk, but are clueless about recognizing new security
flaws. There are a few hundred "True Security Experts" world wide, that have a
firm understanding of Security Architectures, "At Risk" design choices, and
common "everybody does it that way" flaws. About 1/2 of those folks are employed
as senior security IT folks and consultants, the rest are hackers/crackers
(many of which are deep undergound and only known by their handles or reputations).
There is a "retired" core group of "True Security Experts" several times that size,
plus another group of wannabies of a few thousand hackers, crackers, and IT staff
that are pretty cluefull, and learning. Most of these folks you can spot lurking at
conferences, smiling about new flaws, but generally staying in the shadows to avoid
the ego battles.

What separates these groups, is experience and knowledge, and way too much
security by obscurity ... both to protect products, and to protect potential
compromises and exploits.

I think it's worth talking about ... and improving Linux in the process.

John

James DeWitt <jdewitt at verinet.com> writes:
> I'd like to request at this point that we focus on persuasive arguments
> with practical examples and references to further information if possible.
>
> On Sat, Mar 17, 2007 at 07:54:51PM -0600, John L. Bass wrote:
> > Bill Thorson <bill at tstorms.com> writes:
> > > If you are using the default gnome.  There is a "Network Configuration"
> > > tool which requests root password and then lists your network devices.
> > > When you select one and click 'edit' you see as one of your options
> > > "Allow all users to enable and disable the device."  This worked for
> > > me.
> >
> > The security aspects of this are very interesting, as providing root
> > password for the scripts greatly increases the working set of
> > applications and scripts that need to be verified as "trusted". In
> > general this increases the risk of a local machine security flaw, by
> > having even more code in the "must be trusted" class.