[nylug-talk] Weakest Links

[H. G.]

On 8/31/07, Chris Knadle <Chris.Knadle at coredump.us> wrote:
>
> > For example, I remember a while back (2 NYLUG meetings ago), during a
> > discussion on security in Linux compared to that in Windows, it was
> > claimed that we would be better protected if a Linux client machine
> > were compromised due to user separation.
>
>    I don't follow what you're talking about here.


What I meant by "user separation" was the rights granted to "regular" users
and
"root"; ie, "regular users" cannot write to "bin:/sbin: /usr/bin:/usr/sbin",
therefore
they cannot directly modify binaries. During conversations of old on the
subject
of security in Linux, this was often touted.

> That case is weak at best because for one, your home directory is still
> > directly accessible and can be modified by just about every app you run.
> > Something malicious could slip some nastiness into your .bash[rc,
> _profile]
> > or .profile or something.... or perhaps inject something into another
> > applications "dot-directory" that it knows can compromise this other
> > application or startup, etc.  The applications themselves (and their
> > corresponding libraries) may not be compromised, but they do have write
> > access to your home and tmp directories, and can use those to take
> > malicious action against other apps you may have installed, or to
> install
> > rootkits and the like.  (Perhaps I'm being stupid and/or paranoid..)
>
>    Security teams in the various Linux distributions actually do review
> the
> code as well as security reports in order to minimize the chances of
> exploits
> with the applications that are part of the distribution.  I.E. this is
> actually taken into account.
>
>    Can't do that with Windows.


Certainly true. But I'm referring to installed machines being used by
users "in the wild". Just the same way a Windows box gets compromised
post-installation when connected to a network, the same can conceivably
happen to a Linux machine.

If for example, Joe buys an Ubuntu machine from Dell and installs the
latest Firefox.  An exploit was discovered for this "stable" version of
Firefox,
and a trojan is out and about lurking in the ads at popular sites that Joe
is
likely to visit.  Joe visits a site.  Firefox is compromised and
some "badness"
is stuck in his home directory.  The Ubuntu team may discover this and issue
and alert while at the same time upgrading Firefox.  Even though his box
grabs the update, he has already been violated, and the "evil" is still
there,
for example as a .rc file for certain other apps Joe may possibly run.

A finer grained security model would trump this because then you would
be able to say "firefox-bin" is only allowed to access "~/.mozilla",
"~/.firefox"
or what have you, and no other directory.  "~/.nautilus" or "~/.gnome*" is
_none_ of its business, and neither is "~/.bash*", "~/.cshrc" or
"~/.profile".

> We depend on hash fingerprints to verify the package files we grab from
> > our package repositories to be correct, but I'm sure that I recall a
> > while back that it was successfully demonstrated that one could change
> > the contents of a file while producing the same hash? I think it was
> > for MD5, anyway.  Not to mention the fact that there have been a _slew_
> > of compromises on the repository and infrastructure servers of the
> > leading distros (Debian, Ubuntu, Gentoo and $DIETY knows which others)
>
>    Hold it.  The Ubuntu compromise of 5 out of 8 servers were on servers
> that
> held various Forums, and NOT THE PACKAGE REPOSITORIES.  As I previously
> brought up, that compromise has not been shown to be related to the OS
> itself, and there were 15 web packages in use that were not being updated
> and
> perhaps weren't even loaded from the distro itself, which was an ancient
> version of Breezy Badger (v 5.10) which IIRC was considered to be outdated
> as
> of Oct 2005.  Plus unencrypted FTP was in use.  The boxes weren't
> updatable
> due to driver issues, which is why they ended up in neglect.  In short,
> the
> recent Ubuntu compromise are not a good incident to reference here.
>
>    The Debian and Gentoo compromises are more interesting, since at least
> the
> former was due to a bug in the Linux kernel.
>
>    Yes, an MD5 has been shown to be compromisable, and IIRC there's even
> an
> automated tool to do the work.  That's not altogether unsurprising --
> checksums aren't perfect, and if they were you'd only need to store the
> checksum instead of the actual file itself.
>
>    And in terms of security reporting, I very much appreciate the full
> disclosure that Gentoo, Debian, Ubuntu, and others have given us.  That's
> a
> VERY GOOD THING.  If there's a problem, we know.  It gets attention, and
> it
> gets fixed.  Period.


I am not criticizing this; totally agree with you here.

   In contrast, proprietary vendors seem to work hard at killing the
> messenger
> as well as get in the way of security research that would bring any
> negative
> publicity.  Several vulnerabilities go months or even years without fixes.
>
> > Redhat took the vanguard by shipping SELinux with most (all?) of its
> > offerings; it can even be found in Fedora.  There exist many projects
> > like RSBAC, PaX (part of grsecurity).... these should be shipping by
> > default in the leading distros....
>
>    Keep in mind that Fedora and I believe RedHat ship an SELinux
> /targeted/
> policy.  That equates to "users and root at the command line can do
> whatever
> they normally could do before without SELinux", but daemons + applications
> are bound by SELinux.
>    What this boils down to is that strong passwords for user logins are
> still
> very important.


They always were.  In making noise for wider proliferation of
finer-grained security
models, I am not advocating that we ignore obvious common sense.

  The targetted policy is a good compromise between strong
> security and ease-of-use, so I consider it to be a good choice.  Other
> distributions are now shipping with a targetted policy by default, but not
> yet making it active by default, similar to the track Fedora took in
> deploying it at first.  Looks to me like SELinux is slowly gaining
> adoption.
>    I.E. what you want here is already happening.


I'm happy to hear that.

> Anywho, my point is that we haven't addressed a lot of issues that
> > currently exist in Linux today, and even though Windows is the
> > biggest target currently, Linux's increasing popularity
> > and its _wide-scale_ deployment make it an increasingly appealing
> target.
>
>    Linux has been a popular target at least in terms of /servers/ for
> *years*
> now.  Things can always be imporoved, sure.  I don't consider desktop
> Linux
> to be in bad shape in terms of security, although I also haven't seen a
> focused report on the subject.  Anybody got a link?
>
>    Also: what specifically do you consider to be not yet addressed?


I just wanted to harp on the availibility of finer grained security models
in common
distros by default.  Especially now since distros are being offered
preinstalled by
OEMs.

Since you've demonstrated that we're moving closer in that
direction, thats good.
I just wanted to make mention of the fact that we needed a better security model
allowing us to control what individual apps can or can't do, what, for example,
the ports *each _individual_ application*
is allowed to access or not.  Something
a bit more integrated between the firewall/packet filters, file permissions,
and
function call access rights.

Basically the same way that ZFS changed the game by being not simply just
another filesystem, but a full-on amalgamation of volume manager, RAID
_and_ filesystem, I think we're about due for the same sort of phenomenon
in terms of security.  Whats good is that products like these are already in
existence, but I just want to see them a bit more widespread.

I apologize for not being clear enough or making enough sense in my prior
posting.