[ALERT] Security vulnerability with recent OE bitbake.conf changes

[ALERT] Security vulnerability with recent OE bitbake.conf changes

[Paul Sokolovsky]

Hello openembedded-devel,

A commit made some time ago,

http://lists.linuxtogo.org/pipermail/openembedded-commits/2007-April/004912.html

introduced a hole which may lead to unnoticed security vulnerabilities
slipping into the packages/images produced. Specifically, it defines a
random application of a random suite to be used for resolving patching
conflicts/failures. If you don't happen to have that random tool,
patching failure will be silently swallowed, leading to any adverse
effects imaginable - from compile failure to the mentioned security
vulnerabilities.

Proposed solutions:

1. Bring back some reality and switch back to previous default of
dropping to standard shell for resolution:

-TERMCMD ?= "${GNOME_TERMCMD}"
-TERMCMDRUN ?= "${GNOME_TERMCMDRUN}"
+TERMCMD ?= "${SHELLRCCMD}"
+TERMCMDRUN ?= "${SHELLRCCMD}"


2. Add DEPENDS on that random tool, namely gnome-terminal.

If going with choice 2, I proposed also to do the following: 1) add
depends on xine, mplayer, totem, few other video players; 2) add depends
on mesa and show nice 3d rotating menu to select player of user choice;
3) use selected player to show video during the build - after all,
if user deserves comfort of using superfluous GUI tools for conflict
resolution, why one should be bored during normal build process?


Thanks,

-- 
 Paul                          mailto:pmiscml@gmail.com

Re: [ALERT] Security vulnerability with recent OE bitbake.conf changes

[Richard Purdie]

On Thu, 2007-05-03 at 15:47 +0300, Paul Sokolovsky wrote:
> If going with choice 2, I proposed also to do the following: 1) add
> depends on xine, mplayer, totem, few other video players; 2) add depends
> on mesa and show nice 3d rotating menu to select player of user choice;
> 3) use selected player to show video during the build - after all,
> if user deserves comfort of using superfluous GUI tools for conflict
> resolution, why one should be bored during normal build process?

Paul,

Is there really any need for this?

It doesn't encourage me to give a sensible reply, does it...

Richard

Re: [ALERT] Security vulnerability with recent OE bitbake.conf changes

[Richard Purdie]

On Thu, 2007-05-03 at 15:47 +0300, Paul Sokolovsky wrote:
> Hello openembedded-devel,
> 
> A commit made some time ago,
> 
> http://lists.linuxtogo.org/pipermail/openembedded-commits/2007-April/004912.html
> 
> introduced a hole which may lead to unnoticed security vulnerabilities
> slipping into the packages/images produced. Specifically, it defines a
> random application of a random suite to be used for resolving patching
> conflicts/failures. If you don't happen to have that random tool,
> patching failure will be silently swallowed, leading to any adverse
> effects imaginable - from compile failure to the mentioned security
> vulnerabilities.

Patch failure should not be silently swallowed, the builds should abort.
If they don't, we need to fix that underlying problem.

FWIW, your first solution using SHELLRCCMD won't actually work due to
the way IO redirection is done in recent bitbake. 

Your second solution of adding the DEPENDS is impractical due to the
amount of -native packages it would require.

So we need to find the real problem and fix that, probably somewhere in
patch.bbclass an error code isn't being propagated at a guess.

I will also hint at the use of PATCH_RESOLVER = "noop" which means the
user gets the old behaviour of patch failure aborts the build with no
help from any resolver. It should have always been the default but
wasn't. I'm not sure what the current default is but we can change it to
that if its not.

Cheers,

Richard

Re: [ALERT] Security vulnerability with recent OE bitbake.conf changes

[Paul Sokolovsky]

Hello Richard,

Thursday, May 3, 2007, 4:16:39 PM, you wrote:

> On Thu, 2007-05-03 at 15:47 +0300, Paul Sokolovsky wrote:
>> Hello openembedded-devel,
>> 
>> A commit made some time ago,
>> 
>> http://lists.linuxtogo.org/pipermail/openembedded-commits/2007-April/004912.html
>> 
>> introduced a hole which may lead to unnoticed security vulnerabilities
>> slipping into the packages/images produced. Specifically, it defines a
>> random application of a random suite to be used for resolving patching
>> conflicts/failures. If you don't happen to have that random tool,
>> patching failure will be silently swallowed, leading to any adverse
>> effects imaginable - from compile failure to the mentioned security
>> vulnerabilities.


[]

> Is there really any need for this?
> It doesn't encourage me to give a sensible reply, does it...

        Apparently no. But for me, it's pretty clear that even
gnome-terminal shouldn't be used by default, and in expectation of
hardnesses regarding arguing this, I tried to draw picturesquely
absurd "extension", overspiced with few buzzwords. It's of course a
mere small bug otherwise, but I truly looking for solution which won't
by default trouble KDE, other WMs, and classy console guys in favor of
GNOME crowd.


> Patch failure should not be silently swallowed, the builds should abort.
> If they don't, we need to fix that underlying problem.

        Yes, I didn't even bother to ruin my pamphlet with such
down-to-earth triviality ;-). I'd be looking into it as time permits
of course.

> FWIW, your first solution using SHELLRCCMD won't actually work due to
> the way IO redirection is done in recent bitbake. 

> Your second solution of adding the DEPENDS is impractical due to the
> amount of -native packages it would require.

> So we need to find the real problem and fix that, probably somewhere in
> patch.bbclass an error code isn't being propagated at a guess.

> I will also hint at the use of PATCH_RESOLVER = "noop" which means the
> user gets the old behaviour of patch failure aborts the build with no
> help from any resolver. It should have always been the default but
> wasn't. I'm not sure what the current default is but we can change it to
> that if its not.

        Ack, and vote for. Let's have defaults not overloaded with
interactivity, and working along the lines of standard unix/posix
build tools. Frontends, likes one(s) you work on, can have own
config/overrides then. (And few people won't used them anyway, no
matter which potential benefits they give - and not out of
bare-commandline orthodoxy, but because they may have other frontends
relying on classical unix behavior of tools).

> Cheers,

> Richard



-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: [ALERT] Security vulnerability with recent OE bitbake.conf changes

[Justin Patrin]

On 5/3/07, Richard Purdie <rpurdie@rpsys.net> wrote:
> On Thu, 2007-05-03 at 15:47 +0300, Paul Sokolovsky wrote:
> > Hello openembedded-devel,
> >
> > A commit made some time ago,
> >
> > http://lists.linuxtogo.org/pipermail/openembedded-commits/2007-April/004912.html
> >
> > introduced a hole which may lead to unnoticed security vulnerabilities
> > slipping into the packages/images produced. Specifically, it defines a
> > random application of a random suite to be used for resolving patching
> > conflicts/failures. If you don't happen to have that random tool,
> > patching failure will be silently swallowed, leading to any adverse
> > effects imaginable - from compile failure to the mentioned security
> > vulnerabilities.
>
> Patch failure should not be silently swallowed, the builds should abort.
> If they don't, we need to fix that underlying problem.
>
> FWIW, your first solution using SHELLRCCMD won't actually work due to
> the way IO redirection is done in recent bitbake.
>
> Your second solution of adding the DEPENDS is impractical due to the
> amount of -native packages it would require.
>
> So we need to find the real problem and fix that, probably somewhere in
> patch.bbclass an error code isn't being propagated at a guess.
>
> I will also hint at the use of PATCH_RESOLVER = "noop" which means the
> user gets the old behaviour of patch failure aborts the build with no
> help from any resolver. It should have always been the default but
> wasn't. I'm not sure what the current default is but we can change it to
> that if its not.
>

Ummm...where? I tried that in my local.conf and it did nothing. I've
also grepped for PATCH_RESOLVER in both bitbake and oe and found
nothing.

Please, let's remove the gnome-terminal default, it makes no sense to
assume that the lowest common denominator is running bitbake from X...

-- 
Justin Patrin

Re: [ALERT] Security vulnerability with recent OE bitbake.conf changes

[Richard Purdie]

On Sun, 2007-05-06 at 21:29 -0700, Justin Patrin wrote:
> Ummm...where? I tried that in my local.conf and it did nothing. I've
> also grepped for PATCH_RESOLVER in both bitbake and oe and found
> nothing.

Sorry, it should be PATCHRESOLVE = "noop", my memory is playing tricks.

> Please, let's remove the gnome-terminal default, it makes no sense to
> assume that the lowest common denominator is running bitbake from X...

"noop" should be the default. There is no good argument for which
terminal UI should/shouldn't be the default. Ideally I guess it would
autoselect unless the user specifies, I'll give that some thought. A
warning from sanity.bbclass about a missing command might be good too...

Cheers,

Richard

Re: [ALERT] Security vulnerability with recent OE bitbake.conf changes

[Justin Patrin]

On 5/8/07, Richard Purdie <rpurdie@rpsys.net> wrote:
> On Sun, 2007-05-06 at 21:29 -0700, Justin Patrin wrote:
> > Ummm...where? I tried that in my local.conf and it did nothing. I've
> > also grepped for PATCH_RESOLVER in both bitbake and oe and found
> > nothing.
>
> Sorry, it should be PATCHRESOLVE = "noop", my memory is playing tricks.

Ah there we go, thanks a lot. I tried grepping for gnome-terminal and
it hadn't lead me there.

>
> > Please, let's remove the gnome-terminal default, it makes no sense to
> > assume that the lowest common denominator is running bitbake from X...
>
> "noop" should be the default. There is no good argument for which
> terminal UI should/shouldn't be the default. Ideally I guess it would
> autoselect unless the user specifies, I'll give that some thought. A
> warning from sanity.bbclass about a missing command might be good too...
>

It appears not to be, however...:-|

-- 
Justin Patrin

Re: [ALERT] Security vulnerability with recent OE bitbake.conf changes

[Paul Sokolovsky]

Hello Richard,

Thursday, May 3, 2007, 4:16:39 PM, you wrote:

[]

> So we need to find the real problem and fix that, probably somewhere in
> patch.bbclass an error code isn't being propagated at a guess.

        Ok, so here we go: http://bugs.openembedded.org/show_bug.cgi?id=2274

> NOTE: Applying patch 'include-linux-types.patch'
> sh: line 1: gnome-terminal: command not found
> ERROR: Cannot proceed with manual patch resolution - 'gnome-terminal --disable-factory -t "$TERMWINDOWTITLE" -x bash --rcfile $TERMRCFILE' not found. Check TERMCMDRUN variable.
> ERROR: Error in executing: /home/pfalcon/linux-ppc/org.openembedded.dev/packages/dosfstools/dosfstools_2.11.bb
> ERROR: Exception:exceptions.SystemExit Message:1
> ERROR: Printing the environment of the function

Should be clear enough and helpful to whoever may enable manual mode,
but don't have a required terminal app.

> I will also hint at the use of PATCH_RESOLVER = "noop" which means the
> user gets the old behaviour of patch failure aborts the build with no
> help from any resolver. It should have always been the default but
> wasn't. I'm not sure what the current default is but we can change it to
> that if its not.

        Ok, so please review patches above, and let's make these all
changes ;-).

> Cheers,

> Richard



-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: [ALERT] Security vulnerability with recent OE bitbake.conf changes

[Paul Sokolovsky]

Hello,

Tuesday, May 8, 2007, 4:11:03 PM:

> Hello Richard,

> Thursday, May 3, 2007, 4:16:39 PM, you wrote:

> []

>> So we need to find the real problem and fix that, probably somewhere in
>> patch.bbclass an error code isn't being propagated at a guess.

>         Ok, so here we go:
> http://bugs.openembedded.org/show_bug.cgi?id=2274

        This was committed, as well as PATCHRESOLVE set to "noop" by
default.

[]

-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com