On Wed, 02 Aug 2006, in the Usenet newsgroup comp.os.linux.setup, in article
<28b6$44d144e2$c690c3ba$5237@TSOFT.COM>, Rick Moen wrote:

>This is really the crucial point, that we should keep hammering into
>newcomers' consciousness, especially those arriving from MS-Windows:

To a minor extent, this isn't always required. A lot of users are well
beyond their skill levels downloading a tarball (never mind unpacking it
and trying to build). On the other hand, package managers take a lot of
the skills out of the equation. Then you are only somewhat restricted
in hoping that the package is compatible with your distribution. As
mentioned - a blessing and a curse.

>An alarm needs to go off in the back of their heads, whenever they
>find themselves being urged to install fetched-from-elsewhere software
>outside the (signed, vettable-within-reason) packaging regime,
>especially if root-user software is entailed -- telling them they
>_might_ be about to do something risky, unwise, and avoidable.

I can agree with this completely. The modern "popular" Linux
distributions already come with a huge number of applications, and-ons
and eye-candy. The really "popular" ones also have unofficial extras on
their distribution/updates servers if all the supplied stuff isn't
enough. Even learning what they've already got installed (or available
on those distribution CDs) is quite a handful. For those of you with
an 'rpm' based distribution, grab your CDs, and mount them one at a time.
Using Fedora as an example (and assuming the CD is mounted on /mnt/cdrom)
run the command

rpm -qpi /mnt/cdrom/Fedora/RPMS/* > /tmp/FedoraCDx

where x is the number of the CD. This will produce a "package
description' blurb for each package. Expect to take some time reading the
resulting files, as FC5 has 5 CDs, with a total of 2207 packages. In the
1960s, there used to be a radio commercial (advertisement) for a pasta
sauce, where one voice was asking if the product had the "fresh basil,
fresh onions, fresh mushrooms", and so on - and the other voice was
responding to each "It's in there". That's the same thing with the
modern popular Linux distribution. "Does it have $APPLICATIOM?" The
answer usually is "It's in there".

>We want users to have a strong prejudice towards maintained distro packages,
>and a suspicion of any sort of end-run (and not just for reasons of initial
>code risk, but also of ongoing maintenance needs).

Ya gotta _maintain_ this stuff too??? (Sure my Pentium 90 has a virus
checker - it came with it when I bought it back in 1995.)

>Failing that, they can of course learn from Papa Darwin

Read that one to quickly, and was wondering if he's married to Mama Perth

* <---- Perth

>like all the people who installed phpBB, Drupal, AWstats, etc. as tarball
>Web apps a year or two ago, promptly forgot that they'd just assumed
>maintainer duties for that code, and got h4x0red.

That is all to true. We have daily cron jobs that hit the source ftp servers
and websites for the non-standard packages we use. Most of the ftp servers
understand a 'ls -lrt' command (in addition to the default 'dir'), and
the scripts then 'diff' the directory listing, flagging if something has
changed. Someone then manually ftp's into the site, and grabs the newer
version, and sticks this onto a quarantine server, where it is audited
before being forwarded to our updates servers. My guess is that the
Darwin candidates aren't even aware of the concept of updates, never mind
knowing how to do anything about it.

Old guy

Moe Trin writes:
> That's the same thing with the modern popular Linux distribution. "Does
> it have $APPLICATIOM?" The answer usually is "It's in there".

Unfortunately, most new users don't seem to know that. Someone tells them
they need Lilypond to typeset music and they Google it and then try to
download it from the project home page without every looking to see if it
is available from their distribution. Upstream authors usually know who is
packaging their software. It would be helpful if they would provide a
list, or at least a note saying "Foobar is included in many Linux
distributions. We suggest that before downloading our package you check
with yours."
--
John Hasler
john@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA

Rick Moen <rick@linuxmafia.com> wrote in
news:d5ef2$44d29587$c690c3ba$10536@TSOFT.COM:

> chuckcar <chuck@nil.car> wrote:
>
>>> o mpg123 pre0.59s beta was vulnerable to buffer overflow induced by
>>> trojaned (specially malformed) MP3 files played using it, having
>>> binary code in the MP3 frame header that invokes a shell and
>>> recursively deletes the user's home directory. Some showoff who
>>> noticed this bug actually coded a piece of exploit code against
>>> it called JBells (aka Jbellz), that you'll find in some of the
>>> more comprehensive lists of Linux malware. Such as *ahem* mine.
>>>
>>> OK, what did I win, Chuck? ;->
>>>
>>>
>> 0 projects found
>>
>>
>>
>> No matches.
>>
>> is the response from the search on freshmeat.net. I was *very*
>> specific on my criteria. Anybody can rewrite code and callit "their
>> own" but your "project" doesn't exist on freshmeat.net or
>> sourceforge.net.
>
> What's this, then? Chopped liver?
> http://freshmeat.net/projects/mpg123/
>
> (And I'm _extremely_ surprised you aren't aware that mpg123 is one of
> the standard A/V applications.)
>
>

but you didn't say mpg123, you said mpg123 had a security bug, *not*
that it was malware of any form.

--
(setq (chuck nil) car(chuck) )

John Hasler <john@dhh.gt.org> wrote:
> Moe Trin writes:
>> That's the same thing with the modern popular Linux distribution. "Does
>> it have $APPLICATIOM?" The answer usually is "It's in there".
>
> Unfortunately, most new users don't seem to know that. Someone tells them
> they need Lilypond to typeset music and they Google it and then try to
> download it from the project home page without every looking to see if it
> is available from their distribution. Upstream authors usually know who is
> packaging their software. It would be helpful if they would provide a
> list, or at least a note saying "Foobar is included in many Linux
> distributions. We suggest that before downloading our package you check
> with yours."

Well said.

I can't count the number of times I've encountered some person seeking
help solving some problem encountered while locally compiling some very
standard piece of software. One learns to (politely) inquire "_Why_ are
you attempting that? Maybe you're solving the wrong problem?"

99 times out of 100, it turns out there was no compelling reason
whatsoever why the user didn't install his/her distro package -- except
that the user googled on $PROGNAME, found an upstream tarball, and dove
straight in with zero regard to long-term consequence, and no idea about
the alternative.

Remember, to the newcomers, this _all_ looks difficult, and it all looks
outlandish and tortuous. The user sees no sign that he/she is doing
things the difficult (and ill-advised) way.

This is exactly the mindset that the most recent few "Linux worms"
(usually more fairly called PHPXMLRPC / AWstats, etc. worms) have aimed
to exploit: Packaged software and semi-automated maintenance have
removed most of the easy targets (e.g., antique, long-forgotten,
unmaintained BIND8 / rpc.statd / lpr / wuftp / Samba installations),
or at least narrowed the windows of vulnerability for exploitable
network daemons to the point where they're difficult to hit.

What's left? Web apps -- and, in the attacker's ideal case, a nice,
juicy local escalation exploit. All of those PHP things that people
tend _not_ to take from distro packages, but instead from locally set up
and configured tarballs, are the new preferred avenue of entry.

chuckcar <chuck@nil.car> wrote:

> but you didn't say mpg123, you said mpg123 had a security bug, *not*
> that it was malware of any form.

Huh? Somehow, this conversation has managed to go sideways. Let's
review:


>>> If the OP had reason to be worried about some software he got in some
>>> manner - software with the source code would be necessarily
>>> way down the list in any case.
>>
>> Retaining little worries about a piece of untrustworthy software
>> you've fetched from somewhere, for no better reason than having its
>> source code, is a truly _excellent_ way to fool yourself and shoot
>> yourself in the foot. The reasons should be obvious. If not, go and
>> security-audit the source code of the next five desktop applications
>> you use. (For extra fun, make sure they have to parse data from
>> public networks, and go over those input-validation routines
>> carefully!)
>
> Tell you what, you find _one_ named piece of software fitting this
> character on sourceforge.net, freshmeat.net or gnu.org and I'll
> willingly admit I was misinformed on the matter, but until you do, you
> might as well be talking about some code somebody dreged out of a
> newsgroup that only posts code for lovers of viri.


You didn't say anything about my citing upstream source code tarballs
with _malware_ in them (but see below, anyway). I had spoken of false
assurance from merely having a source tarball, since one must always
beware of security problems _in_ upstream tarballs. Malware is the
_least_ of one's worries, in that department. Among the biggest such
worries, typically, are input-validation routines.

That, of course, was exactly the point of the example I cited: The
mpg123 beta's input-validation bug was (immediately) exploited by the
JBells/Jbellz 'sploit author. Thus my point: A user who downloaded the
mpg123 source tarball from the upstream ftp site would have gotten
vulnerable code: The user implicitly assumes all of the normal duties
assumed by a package-maintainer, and, unless he/she actually _does_
that (which is stunningly unlikely) is at much greater risk.

I hope you don't think that package maintainers merely grab the latest
head version from upstream, write a .spec file, and build packages
without any other work! There's a whole lot more to it than that -- and
quite a few upstream versions of security-sensitive packages (e.g.,
glibc) end up getting deliberately passed over by packagers on account
of such problems.

However, since you _now_ say you want examples of inline -=malware=- in
upstream tarballs, I'll give you not one but several:

o On January 21, 1999, source tarball tcp_wrappers_7.6.tar.gz at
ftp.win.tue.nl at Eindhoven University (near maintainer Wietse Venema)
was trojaned by an intruder who'd rooted the ftp site. Several
hundred unwary users downloaded the trojaned source code, according
to logfiles.

o On January 23, 1999, the same thing happened with util-linux
development release 2.9g source code on the same ftp site. Again,
numerous unwary downloaders were clobbered.

o On September 28, 2002, ftp.sendmail.org server was site-compromised
and trojaned source-code packages of sendmail 8.12.6 were offered there
for eight days before the breach was noticed.

o On July 30, 2002, the same thing happened to ftp.openssh.com,
trojaning the developers' source tarballs of the OpenSSH 3.2.2p1,
3.4p1, and 3.4 development source code.

o In March 2003, monkey.org and irssi.org download sites were likewise
site-compromised, leading immediately to replacement of the genuine
source tarballs for security tools dsniff, fragrouter, and fragroute,
and IRC client irssi, with trojaned versions. The compromise went
undetected for seven days.

o On November 5, 2003 (Guy Fawkes Day -- heh), someone trojaned one of
the master CVS-checkout sites for the Linux kernel, namely
kernel.bkbits.net . Larry McVoy caught this action within hours
because of an automated check built into the then-operational
software gateway from BitKeeper.

Just one additional point: In each of those cases, the exploit code was
quite subtle: Unless you were _very_ paranoid and devoted time and
attention to reading the code, you'd not have found it.

In fact, one of the standard ways of making such scrutiny less necessary
is gpg-signing: Most of the above trojanings could have been caught by
a downloader being sufficiently paranoid to check the gpg signatures
against a believed-to-be-valid maintainer's public key. Two of the
sites' projects (at monkey.org and irssi.org) _started_ the practice of
gpg-signing the day after their respective compromises.

And that (checking upstream authors' gpg signatures on source code)
is yet another of the responsibilities routinely carried out by a distro
package maintainer -- which accordingly gets dropped in _your_ lap if
you rely on upstream tarballs.

Do you take care of all of those duties? Skipping over upstream
releases with too many problems? Local-distro patching of that
upstream source to comply with your distro's policies about directory
trees, etc.? gpg-checking? Other quality control?

If you do, good for you! However, you'd be one in a million -- and
taking on twhose onerous duties if there are acceptable distro-packaged
alternatives is just nuts.

--
Cheers,
Rick Moen Frater Magnus vos spectat.
rick@linuxmafia.com

Rick Moen wrote:

> 99 times out of 100, it turns out there was no compelling reason
> whatsoever why the user didn't install his/her distro package --
> except that the user googled on $PROGNAME, found an upstream tarball,
> and dove straight in with zero regard to long-term consequence, and
> no idea about the alternative.

That, and they found wordy posts about how to get it running from before the
software was integrated. Bugzilla used to be this way, before it was finally
integrated into the Fedora Core "Extras" packages, and it's still not
trivially available for older RedHat releases as an RPM. (I've written RPM's
for it in the past: it got nasty to do, due to all the Perl module
dependencies and CPAN's habit of grabbing the very latest, greatest, not
necessarily tested with Bugzilla versions of all the package dependencies.)

> This is exactly the mindset that the most recent few "Linux worms"
> (usually more fairly called PHPXMLRPC / AWstats, etc. worms) have
> aimed to exploit: Packaged software and semi-automated maintenance
> have removed most of the easy targets (e.g., antique, long-forgotten,
> unmaintained BIND8 / rpc.statd / lpr / wuftp / Samba installations),
> or at least narrowed the windows of vulnerability for exploitable
> network daemons to the point where they're difficult to hit.

Well, they would have eliminated those if more of the default setups
automatically turned on updates. Few do: but yeah, a lot of quality of tools
has improved.

> What's left? Web apps -- and, in the attacker's ideal case, a nice,
> juicy local escalation exploit. All of those PHP things that people
> tend _not_ to take from distro packages, but instead from locally set
> up and configured tarballs, are the new preferred avenue of entry.

Rick Moen <rick@linuxmafia.com> wrote in
news:2bbdc$44d2dcb4$c690c3ba$23072@TSOFT.COM:

> chuckcar <chuck@nil.car> wrote:
> >>>> If the OP had reason to be worried about some software he got in
>>>> some manner - software with the source code would be necessarily
>>>> way down the list in any case.
>>>
>>> Retaining little worries about a piece of untrustworthy software
>>> you've fetched from somewhere, for no better reason than having its
>>> source code, is a truly _excellent_ way to fool yourself and shoot
>>> yourself in the foot. The reasons should be obvious. If not, go
>>> and security-audit the source code of the next five desktop
>>> applications you use. (For extra fun, make sure they have to parse
>>> data from public networks, and go over those input-validation
>>> routines carefully!)
>>
>> Tell you what, you find _one_ named piece of software fitting this
>> character on sourceforge.net, freshmeat.net or gnu.org and I'll
>> willingly admit I was misinformed on the matter, but until you do,
>> you might as well be talking about some code somebody dreged out of a
>> newsgroup that only posts code for lovers of viri.
>
>
> You didn't say anything about my citing upstream source code tarballs
> with _malware_ in them (but see below, anyway). I had spoken of false
> assurance from merely having a source tarball, since one must always
> beware of security problems _in_ upstream tarballs. Malware is the
> _least_ of one's worries, in that department. Among the biggest such
> worries, typically, are input-validation routines.


That was *exactly* what I was talking about and if you were unsure of
what I meant, you could have asked - water under the bridge.

> That, of course, was exactly the point of the example I cited: The
> mpg123 beta's input-validation bug was (immediately) exploited by the
> JBells/Jbellz 'sploit author. Thus my point: A user who downloaded
> the mpg123 source tarball from the upstream ftp site would have gotten
> vulnerable code: The user implicitly assumes all of the normal duties
> assumed by a package-maintainer, and, unless he/she actually _does_
> that (which is stunningly unlikely) is at much greater risk.

Still a security bug - probably already fixed as well anyways - not
malware.


> I hope you don't think that package maintainers merely grab the latest
> head version from upstream, write a .spec file, and build packages
> without any other work! There's a whole lot more to it than that --
> and quite a few upstream versions of security-sensitive packages
> (e.g., glibc) end up getting deliberately passed over by packagers on
> account of such problems.
>
> However, since you _now_ say you want examples of inline -=malware=-
> in upstream tarballs, I'll give you not one but several:
>
> o On January 21, 1999, source tarball tcp_wrappers_7.6.tar.gz at
> ftp.win.tue.nl at Eindhoven University (near maintainer Wietse
> Venema) was trojaned by an intruder who'd rooted the ftp site.
> Several hundred unwary users downloaded the trojaned source code,
> according to logfiles.

not sourceforge.net freshmeat.net or gnu.org - just a news headline.

> o On January 23, 1999, the same thing happened with util-linux
> development release 2.9g source code on the same ftp site. Again,
> numerous unwary downloaders were clobbered.
>
> o On September 28, 2002, ftp.sendmail.org server was site-compromised
> and trojaned source-code packages of sendmail 8.12.6 were offered
> there for eight days before the breach was noticed.
>
> o On July 30, 2002, the same thing happened to ftp.openssh.com,
> trojaning the developers' source tarballs of the OpenSSH 3.2.2p1,
> 3.4p1, and 3.4 development source code.
>
> o In March 2003, monkey.org and irssi.org download sites were
> likewise
> site-compromised, leading immediately to replacement of the genuine
> source tarballs for security tools dsniff, fragrouter, and
> fragroute, and IRC client irssi, with trojaned versions. The
> compromise went undetected for seven days.
>
> o On November 5, 2003 (Guy Fawkes Day -- heh), someone trojaned one
> of
> the master CVS-checkout sites for the Linux kernel, namely
> kernel.bkbits.net . Larry McVoy caught this action within hours
> because of an automated check built into the then-operational
> software gateway from BitKeeper.
>
> Just one additional point: In each of those cases, the exploit code
> was quite subtle: Unless you were _very_ paranoid and devoted time
> and attention to reading the code, you'd not have found it.

But none of them were the *original* code. It happens, but in terms of
numbers, I'm worrying more about lightening strikes to my cranium on a
sunny day - and that *is* the point - needlessly worrying the OP.


> In fact, one of the standard ways of making such scrutiny less
> necessary is gpg-signing: Most of the above trojanings could have
> been caught by a downloader being sufficiently paranoid to check the
> gpg signatures against a believed-to-be-valid maintainer's public key.
> Two of the sites' projects (at monkey.org and irssi.org) _started_
> the practice of gpg-signing the day after their respective
> compromises.
>
> And that (checking upstream authors' gpg signatures on source code)
> is yet another of the responsibilities routinely carried out by a
> distro package maintainer -- which accordingly gets dropped in _your_
> lap if you rely on upstream tarballs.
>
> Do you take care of all of those duties? Skipping over upstream
> releases with too many problems? Local-distro patching of that
> upstream source to comply with your distro's policies about directory
> trees, etc.? gpg-checking? Other quality control?
>
> If you do, good for you! However, you'd be one in a million -- and
> taking on twhose onerous duties if there are acceptable
> distro-packaged alternatives is just nuts.
>
And you *know* that gnu.org et al *don't* do that?

Look the point was to show me that it is *likely* that a person
downloading *linux* software from one of it's distribution "centres" is
likely to get malware in the process. I even gave you better odds: I
asked you to name 1 piece of software the was like that. You couldn't,
so the point has been shown (short of an exaustive census of *all* linux
software on the internet) that the odds are *extremely* remote - and
hence not something to look at - certainly not in the first response to
a user with a linux problem.

--
(setq (chuck nil) car(chuck) )

chuckcar <chuck@nil.car> wrote:

> That was *exactly* what I was talking about and if you were unsure of
> what I meant, you could have asked - water under the bridge.

No problem.

[mpg123 beta:]

> Still a security bug - probably already fixed as well anyways - not
> malware.

Well, of _course_ it was fixed -- the same day the JBells/JBellz exploit
emerged. I can't help thinking you're going far out of your way to
ignore my point, though.

[tcp wrappers 7.6:]

> not sourceforge.net freshmeat.net or gnu.org - just a news headline.

What's _this_, then? Smoked herring? Liverwurst?
http://freshmeat.net/projects/tcp_wrappers/

[Trojaning of master source tarballs of util-linux, sendmail, OpenSSH,
irssi, monkey.org security tools, and the CVS master copy of the Linux
kernel:]

> But none of them were the *original* code.

Irrelevant to the point: The point is that only an extremely wary
downloader of source tarballs would be able to _tell_ it wasn't the
original code (that the source had been trojaned) -- and, in the case of
irssi and the monkey.org tools, which only later used code signing, it
would have been nearly impossible.

> It happens, but in terms of numbers, I'm worrying more about
> lightening strikes to my cranium on a sunny day - and that *is* the
> point - needlessly worrying the OP.

I assume you mean grabbing source tarballs from upstream site, not doing
security vetting, and not doing quality control. For your sake, I hope
fortune smiles upon you. You'll need it. And I devoutly hope that
others don't follow your example.

[Package-maintainers' quality control duties -- not to mention checking
gpg-signatures:]

> And you *know* that gnu.org et al *don't* do that?

I offer the disaster that was glibc 2.0.7 as Exhibit A. The prosecution
rests.

Sensible people (those who didn't just use upstream source without
thinking) carefully avoided 2.0.7 except as heavily patched by distros.

> Look the point was to show me that it is *likely* that a person
> downloading *linux* software from one of it's distribution "centres" is
> likely to get malware in the process.

No, sir. You are moving the goalposts at this point. I don't blame
you, since your original position (which I addressed) was completely
untenable.

A person downloading and using upstream source tarballs is merely taking
on additional, usually avoidable maintainer / vetting / quality-control
duties, usually being unaware of same, and is also encountering
additional, usually avoidable security and quality risk. Thus my point.

> I even gave you better odds: I asked you to name 1 piece of software
> the was like that. You couldn't,

Actually, to the contrary, I gave you about a half-dozen. Those
particular examples are, of course, no longer current versions -- but
you never know where and when it might happen again. Thus my other
point.

> so the point has been shown (short of an exaustive census of *all* linux
> software on the internet) that the odds are *extremely* remote - and
> hence not something to look at - certainly not in the first response to
> a user with a linux problem.

To the contrary: Good system-maintenance practices are worth stressing
at any time, especially when you see a clear probable sign that the
querent is in the habit of doing something dumb.

It is apparent that you are a fan of doing things the wrong way. Good
luck to you.

--
Cheers, Your eyes are weary from staring at the CRT. You feel
Rick Moen sleepy. Notice how restful it is to watch the cursor
rick@linuxmafia.com blink. Close your eyes. The opinions stated above are
yours. You cannot imagine why you ever felt otherwise.

Rick Moen <rick@linuxmafia.com> wrote in
news:8ccc2$44d3dd15$c690c3ba$503@TSOFT.COM:

>
>

Well, you apparently have different methods of find the source of a problem
- which is the purpose of this NG after all. Good luck to you doing it,
although I'm virtually certain that your method will mean that search takes
much longer.

--
(setq (chuck nil) car(chuck) )

On Fri, 04 Aug 2006, in the Usenet newsgroup comp.os.linux.setup, in article
<4457f$44d2d342$c690c3ba$20605@TSOFT.COM>, Rick Moen wrote:
>John Hasler <john@dhh.gt.org> wrote:

>> Moe Trin writes:
>>> That's the same thing with the modern popular Linux distribution. "Does
>>> it have $APPLICATIOM?" The answer usually is "It's in there".
>>
>> Unfortunately, most new users don't seem to know that.

That's a major problem - we've got all this "stuff", and the users don't
know that, or even how to find out what it might be. Part of this is a
sign of the times and it's our problem because we're keeping up with the
Jones - or in this case, the Gates. "Windoze has this application that can
do $THAT" and someone therefore sees the need to create a *nix application
that will do $THAT and more. Most people don't know all of the stuff you
can get for windoze, why should we expect anything different in *nix?

>> It would be helpful if they would provide a list, or at least a note
>> saying "Foobar is included in many Linux distributions. We suggest that
>> before downloading our package you check with yours."
>
>Well said.

Seconded.

>99 times out of 100, it turns out there was no compelling reason
>whatsoever why the user didn't install his/her distro package -- except
>that the user googled on $PROGNAME, found an upstream tarball, and dove
>straight in with zero regard to long-term consequence, and no idea about
>the alternative.

I sometimes see another reason - version number chasing. Gotta have the
very latest one, you know. Otherwise, the neighbors will look down on you
or somethin'. The fact that the distribution may not feel comfortable
with the latest bleeding edge version is beyond their understanding.

>This is exactly the mindset that the most recent few "Linux worms"
>(usually more fairly called PHPXMLRPC / AWstats, etc. worms) have aimed
>to exploit:

"Oh, but I need the features in PHP5" (even though they haven't quite
mastered the basic concept of a web server)

>Packaged software and semi-automated maintenance have removed most of the
>easy targets (e.g., antique, long-forgotten, unmaintained BIND8 / rpc.statd
>/ lpr / wuftp / Samba installations), or at least narrowed the windows of
>vulnerability for exploitable network daemons to the point where they're
>difficult to hit.

Is anyone still supplying wu-ftpd? I know that both of the windoze wannabe
malware detectors (chkrootkit and rkhunter) are still looking for signs of
the Ramen worm that attacked wu-ftpd-2.6.0-3 from Red Hat 6.2, but that
worm was specifically banner reading to find vulnerable systems (none of
the other distributions were attacked, even if using the same or earlier
release of wu-ftpd).

The distributions are also a lot smarter than before. When was the last time
you saw a MTA installed with an open relay capability. Heck, you've got to
work to get them to do so now. Likewise, we're seeing more of Theo's
philosophy that the box should be secure by default with services disabled,
and the user has to figure out how to enable things.

One other "feature" I greet with _very_ mixed opinion is the security
helpers that silently reset ownership and permissions to "safe" values.
This may or may not help newbies (may not, because they may not even know
what 'chown' and 'chmod' are), but they're another step in the "let me
help you be safe" concept.

>What's left? Web apps -- and, in the attacker's ideal case, a nice,
>juicy local escalation exploit. All of those PHP things that people
>tend _not_ to take from distro packages, but instead from locally set up
>and configured tarballs, are the new preferred avenue of entry.

Last 30 days on Bugtraq, the string 'PHP' is in about 13 percent of the
articles, and most Linux users don't even know what that mailing list
covers.

Old guy