Rick Moen wrote:
> Nico Kadel-Garcia <nkadel@comcast.net> wrote:
>> Rick Moen wrote:
>
>>> I say this with some trepidation, because it could be seen as a slam
>>> against our Scarlet Chapeau-wearing friends (and I do not so intend,
>>> nor do I engage in distro-bashing generally): There seems to be a
>>> very common misconception among (many) users of RPM-based
>>> distributions, and particularly of Red Hat [Enterprise] Linux, that
>>> one cannot build packages unless one is wielding root-user
>>> authority.
>>
>> Agreed. But there are some security reasons: for example, the
>> behavior of LD_LIBRARY_PATH is different for mere mortal users than
>> it is for root, and it can be worth building as root to make sure
>> you haven't incorporated any dependencies on that variable.
>
> Obligatory mention: LD_LIBRARY_PATH is bad.
> http://www.visi.com/~barr/ldpath.html
>
>> It can also help prevent someone slipping a
>> fascinating library into a local directory, to be compiled by the
>> builder and published as an RPM, and cause people to go nuts
>> figuring out where it came from.
>
> You know, if I have to worry about people slipping in a file into a
> 0700 build directory tree owned by me alone, I've got bigger problems
> than the security of my build system. ;->

Like using NFS home directories?

Nico Kadel-Garcia <nkadel@comcast.net> wrote:

>> than the security of my build system. ;->
>
> Like using NFS home directories?

I bow to nobody in considering NFS-mounted home directories the fifth
horseman of the Apocalpse ;-> . However, if called upon, in that
situation, to build software packages as a non-root user, I'd probably
limit the damage in some fashion like this:

$ su -
# mkdir /usr/local/src/buildfarm #if that's on local disc
# chown rick:rick /usr/local/src/buildfarm
# chmod 6700 /usr/local/src/buildfarm
# exit
$

The dotfiles being on NFS "~" would be worrisome, so I might want to
fix that manually each time before building anything -- and, well, maybe
even go strictly local -- and, well, insert corporate-LAN security
nightmare here. ;->

(Above probably has some flaws I haven't thought through, and I'm
a little rushed at the moment, but I'm sure you get what I'm driving
at.)

On Wed, 2 Aug 2006 14:17:44 -0400, "Nico Kadel-Garcia" <nkadel@comcast.net> wrote:

>Rick Moen wrote:
....
>> You know, if I have to worry about people slipping in a file into a
>> 0700 build directory tree owned by me alone, I've got bigger problems
>> than the security of my build system. ;->
>
>Like using NFS home directories?
>
I've settled on an NFS rw export that each machine uses for common stuff,
like source tarballs, patches. I've never quite trusted the /home/username
'roving user' concept, though is has some attractions.

These days one doesn't extract a source tarball as root, bad things could
happen even before reading the docs, let alone starting the build process.

Exception? Those binary driver shell scripts like the nVidia driver, one
has to trust they gonna do the right thing...

Grant.

Rick Moen <rick@linuxmafia.com> wrote in
news:d51b3$44d06d56$c690c3ba$5743@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.

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

On Tue, 01 Aug 2006, in the Usenet newsgroup comp.os.linux.setup, in article
<ce83e$44cfe98f$c690c3ba$12413@TSOFT.COM>, Rick Moen wrote:

>There seems to be a very common misconception among (many) users of
>RPM-based distributions, and particularly of Red Hat [Enterprise] Linux,
>that one cannot build packages unless one is wielding root-user authority.

Now, I can't comment on RHEL (don't use it), but I think this was a common
concept as far back as rpp in RHL <2.0 (1995).

>I believe this is because doing compiles inside /usr/src/redhat (with
>root authority) _was_ in fact the standard means at the time that RH
>started becoming popular -- and remains very much the path of least
>resistance. So, I hear that from people all the time.

Agreed. The /usr/src/redhat/ tree was owned by root:root, and there were
several solutions. At one time, we were changing the ownership of the tree
to a special user/group - 'rpmbuilder' comes to mind (I remember that one
distribution - don't recall which - came with that tree owned by a special
unpriviledged user - perhaps 'rpm', but that was a while ago). There was
also the capability of using a 'buildroot' option that allowed you to build
the package elsewhere. We didn't do that much in the line of building
packages, other than on a development system quite removed from the
local network, so if that system got trashed, it was no big deal. The
main building rational was to get "compatible" packages that would install
based on source RPMs from other distributions (usually SuSE and Conectiva
as I recall). Might have to edit the spec files to handle the local warts,
but we rarely did serious package building.

>I'm every bit as guilty of this as most people: It's a bit of a pain in
>the neck to set up the build-dir and dotfile contents necessary to
>_avoid_ the need for root access -- and I'm actually typing this on an
>RHEL laptop where I, too, haven't bothered. (I did, then somehow lost
>the dotfile stuff, and hadn't redone it yet -- but hadn't needed to
>build RPMs recently, so I have an excuse.)

A bit on the general side, but the only reason we used locally built binary
packages was to get things under the package manager for ease of updating.
A local package will _rarely_ satisfy some other package's dependency.
Package FOO is dependent on a specific package BAR, not just any package
with that name. The convenience is the only benefit that locally built
rpm binaries have over tarballs. Neither will satisfy the dependency
requirements of some other package (unless you also created that package
as well).

I don't know about you, but I don't expect newbies up to experienced
_users_ (as opposed to people who are comfortable hacking code) to be
building packages. Even compiling tarballs isn't a common task for users,
never mind newbies. It boils down to the fact that such people really
should be limiting their installs to packages supplied by their
distribution for their release. This eliminates the main dependencies
and security problems. Stuff from hardware manufacturers and the better known
archives like sunsite or sourceforge is probably OK too, but it's up to
the individual to be sure that the package is built for their specific
distribution and release. A package built for (example) Red Hat 9 is not
going to work well in a Mandriva 2006 or SuSE 10.1 installation (although
both use rpm as the package manager), and even something built for Fedora
Core 4 isn't guaranteed to work in FC 5. This is both the benefit and
curse of a wide open operating system.

Old guy

Moe Trin <ibuprofin@painkiller.example.tld> wrote:

[sharing recollections about past schemes for non-root RPM-building,
then:]

> I don't know about you, but I don't expect newbies up to experienced
> _users_ (as opposed to people who are comfortable hacking code) to be
> building packages. Even compiling tarballs isn't a common task for users,
> never mind newbies. It boils down to the fact that such people really
> should be limiting their installs to packages supplied by their
> distribution for their release. This eliminates the main dependencies
> and security problems. Stuff from hardware manufacturers and the better known
> archives like sunsite or sourceforge is probably OK too, but it's up to
> the individual to be sure that the package is built for their specific
> distribution and release.

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

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. 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).

Failing that, they can of course learn from Papa Darwin, instead -- 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.

chuckcar <chuck@nil.car> wrote:

>> 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.

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? ;->

Grant wrote:
> On Wed, 2 Aug 2006 14:17:44 -0400, "Nico Kadel-Garcia"
> <nkadel@comcast.net> wrote:
>
>> Rick Moen wrote:
> ...
>>> You know, if I have to worry about people slipping in a file into a
>>> 0700 build directory tree owned by me alone, I've got bigger
>>> problems than the security of my build system. ;->
>>
>> Like using NFS home directories?
>>
> I've settled on an NFS rw export that each machine uses for common
> stuff,
> like source tarballs, patches. I've never quite trusted the
> /home/username 'roving user' concept, though is has some attractions.
>
> These days one doesn't extract a source tarball as root, bad things
> could
> happen even before reading the docs, let alone starting the build
> process.
>
> Exception? Those binary driver shell scripts like the nVidia driver,
> one
> has to trust they gonna do the right thing...

They don't. Do you wnat my rewrite of them?

Rick Moen <rick@linuxmafia.com> wrote in
news:5b9b9$44d1464a$c690c3ba$5902@TSOFT.COM:

> chuckcar <chuck@nil.car> wrote:
>
>>> 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.
>
> 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. Your
example just doesn't make it. It's more in line with my last sentence in
my previous post. I retain my point.


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

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.)