FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Hardened

 
 
LinkBack Thread Tools
 
Old 12-29-2011, 10:09 PM
"Tóth Attila"
 
Default hardened-sources & tp_smapi, firefox-9.0 install stucks

Positive feedback:
New tp_smapi ebuild (0.41) based on the forked Debian source compiles fine
with hardened-sources-3.1.5 and hardened-sources-3.1.6, but fails with gcc
plugin errors with hardened-source versions before (3.1.1-r1, 3.1.4-r1).

Negative feedback:
firefox-9.0 ebuild stalls at the install phase while xpcshell command tops
CPU usage for hours. Shutting down the process makes the ebuild die.
Issuing the command again on the compiled sources triggers the same error.

Regards:
Dw.
--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057
 
Old 12-30-2011, 11:28 AM
Sven Vermeulen
 
Default hardened-sources & tp_smapi, firefox-9.0 install stucks

On Fri, Dec 30, 2011 at 12:09:18AM +0100, "Tóth Attila" wrote:
> Negative feedback:
> firefox-9.0 ebuild stalls at the install phase while xpcshell command tops
> CPU usage for hours. Shutting down the process makes the ebuild die.
> Issuing the command again on the compiled sources triggers the same error.

Regarding the firefox issue, I don't know if a bug is already opened for
that, but the solution is to paxmark -r (disable RANDMMAP) both xpcshell
(you'll need to edit the ebuild to do so or do it before it starts in the
install phase) and the resulting firefox binary (on the system).

Wkr,
Sven Vermeulen
 
Old 12-30-2011, 08:12 PM
Wirt Wolff
 
Default hardened-sources & tp_smapi, firefox-9.0 install stucks

Excerpts from Sven Vermeulen's message of Fri Dec 30 05:28:01 -0700 2011:
> On Fri, Dec 30, 2011 at 12:09:18AM +0100, "Tóth Attila" wrote:
> > Negative feedback:
> > firefox-9.0 ebuild stalls at the install phase while xpcshell command tops
> > CPU usage for hours. Shutting down the process makes the ebuild die.
> > Issuing the command again on the compiled sources triggers the same error.
>
> Regarding the firefox issue, I don't know if a bug is already opened for
> that, but the solution is to paxmark -r (disable RANDMMAP) both xpcshell
> (you'll need to edit the ebuild to do so or do it before it starts in the
> install phase) and the resulting firefox binary (on the system).
>

For reference the associated bug is

- <bug# 396275> www-client/firefox 9.0 and xpcshell on grsec/pax kernel
run into infinite loop doing mmap/munmap, need paxctl -r

--
Regards,
Wirt
 
Old 12-30-2011, 10:57 PM
"Tóth Attila"
 
Default hardened-sources & tp_smapi, firefox-9.0 install stucks

Thanks for the info.
I'm screaming into my pillow.

--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

2011.December 30.(P) 22:12 idÅ‘pontban Wirt Wolff ezt Ã*rta:
> Excerpts from Sven Vermeulen's message of Fri Dec 30 05:28:01 -0700 2011:
>> On Fri, Dec 30, 2011 at 12:09:18AM +0100, "Tóth Attila" wrote:
>> > Negative feedback:
>> > firefox-9.0 ebuild stalls at the install phase while xpcshell command
>> tops
>> > CPU usage for hours. Shutting down the process makes the ebuild die.
>> > Issuing the command again on the compiled sources triggers the same
>> error.
>>
>> Regarding the firefox issue, I don't know if a bug is already opened for
>> that, but the solution is to paxmark -r (disable RANDMMAP) both
>> xpcshell
>> (you'll need to edit the ebuild to do so or do it before it starts in
>> the
>> install phase) and the resulting firefox binary (on the system).
>>
>
> For reference the associated bug is
>
> - <bug# 396275> www-client/firefox 9.0 and xpcshell on grsec/pax kernel
> run into infinite loop doing mmap/munmap, need paxctl -r
>
> --
> Regards,
> Wirt
>
>
 
Old 12-31-2011, 11:05 AM
 
Default hardened-sources & tp_smapi, firefox-9.0 install stucks

On 30 Dec 2011 at 13:28, Sven Vermeulen wrote:

> Regarding the firefox issue, I don't know if a bug is already opened for
> that, but the solution is to paxmark -r (disable RANDMMAP) both xpcshell
> (you'll need to edit the ebuild to do so or do it before it starts in the
> install phase) and the resulting firefox binary (on the system).

no, that's pretty much never a solution , better fix the bug, see bugzilla.
 
Old 12-31-2011, 12:43 PM
"Tóth Attila"
 
Default hardened-sources & tp_smapi, firefox-9.0 install stucks

Isn't it miserable to see, that as time is passing by, more and more
important softwares (java, python, libreoffice, firefox) conflict with
more and more PAX restrictions?
I would expect exactly the opposite. But it seems, that developers become
less and less aware (or care less) about security.

Nowdays I would rather run libreoffice and firefox in a jail. But I have
no time to set up an environment and grsec policy for it.
--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

2011.December 31.(Szo) 13:05 idÅ‘pontban pageexec@freemail.hu ezt Ã*rta:
> On 30 Dec 2011 at 13:28, Sven Vermeulen wrote:
>
>> Regarding the firefox issue, I don't know if a bug is already opened for
>> that, but the solution is to paxmark -r (disable RANDMMAP) both
>> xpcshell
>> (you'll need to edit the ebuild to do so or do it before it starts in
>> the
>> install phase) and the resulting firefox binary (on the system).
>
> no, that's pretty much never a solution , better fix the bug, see
> bugzilla.
>
>
 
Old 12-31-2011, 11:39 PM
7v5w7go9ub0o
 
Default hardened-sources & tp_smapi, firefox-9.0 install stucks

On 12/31/11 08:43, "Tóth Attila" wrote:
> Isn't it miserable to see, that as time is passing by, more and more
> important softwares (java, python, libreoffice, firefox) conflict
> with more and more PAX restrictions? I would expect exactly the
> opposite. But it seems, that developers become less and less aware
> (or care less) about security.
>
> Nowdays I would rather run libreoffice and firefox in a jail. But I
> have no time to set up an environment and grsec policy for it.

Heh...better yet; using VMs - with optional hardware assistance.

Joanna Rutkowska of <http://theinvisiblethings.blogspot.com/> , who is
well-known as an effective white-hat cracker, is developing a "secure"
OS she calls Qubes <http://qubes-os.org/Home.html>

She's presently using fedora as the Linux source distribution, but
there's been a lot of enthusiastic discussion among some of the beta
testers about changing to Gentoo
<https://groups.google.com/group/qubes-devel/browse_thread/thread/588399cdd43da28c#>
and some of these guys seem poised to go for it.

Should the switch occur, one would painlessly have hardened Gentoo VMs,
managed by a XEN bare-metal hypervisor.

In the case of Firefox 9.0 (actually, now Firefox 9.0.1), one could
safely continue with Firefox 8.0 in temporary ("disposable") VMs 'til
the Gentoo developers (who are volunteers, generously donating personal
time) get a chance to address the issue.
 
Old 01-01-2012, 01:22 AM
"Tóth Attila"
 
Default hardened-sources & tp_smapi, firefox-9.0 install stucks

I'm aware of Qubes. But as long as it is based on rpms, I won't make the
time investment necessary for studying it.
It would be good if Joanna would realize, that a source based rolling
distro is easier to handle for their purposes. I haven't aware this was
addressed on the mailing list. BTW Laszlo Zrubecz is a Hungarian guy. But
I don't know him.

Handling the firefox situation at the ebuild level is pretty simple, since
we have pax-marking available now for use. The real solution would be to
teach upstream about security and proper memory handling. As it was
mentioned by paxteam and others as well. Like it is not just erroneous
from the security point of view, but the whole concept of fixed address
mmap is not correct.

It would be good not to think about disposable VMs because of
security-blind applications. I still haven't give it up. I hope 2012 will
be better! :-)

Happy New year:
Dw. (Central European Timezone)
--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

2012.Január 1.(V) 01:39 idÅ‘pontban 7v5w7go9ub0o ezt Ã*rta:
> On 12/31/11 08:43, "T?th Attila" wrote:
>> Isn't it miserable to see, that as time is passing by, more and more
>> important softwares (java, python, libreoffice, firefox) conflict
>> with more and more PAX restrictions? I would expect exactly the
>> opposite. But it seems, that developers become less and less aware
>> (or care less) about security.
>>
>> Nowdays I would rather run libreoffice and firefox in a jail. But I
>> have no time to set up an environment and grsec policy for it.
>
> Heh...better yet; using VMs - with optional hardware assistance.
>
> Joanna Rutkowska of <http://theinvisiblethings.blogspot.com/> , who is
> well-known as an effective white-hat cracker, is developing a "secure"
> OS she calls Qubes <http://qubes-os.org/Home.html>
>
> She's presently using fedora as the Linux source distribution, but
> there's been a lot of enthusiastic discussion among some of the beta
> testers about changing to Gentoo
> <https://groups.google.com/group/qubes-devel/browse_thread/thread/588399cdd43da28c#>
> and some of these guys seem poised to go for it.
>
> Should the switch occur, one would painlessly have hardened Gentoo VMs,
> managed by a XEN bare-metal hypervisor.
>
> In the case of Firefox 9.0 (actually, now Firefox 9.0.1), one could
> safely continue with Firefox 8.0 in temporary ("disposable") VMs 'til
> the Gentoo developers (who are volunteers, generously donating personal
> time) get a chance to address the issue.
>
>
>
>
>
 
Old 01-01-2012, 04:12 AM
Wirt Wolff
 
Default hardened-sources & tp_smapi, firefox-9.0 install stucks

Excerpts from Tóth Attila's message of Sat Dec 31 19:22:11 -0700 2011:
>
> Handling the firefox situation at the ebuild level is pretty simple, since
> we have pax-marking available now for use. The real solution would be to
> teach upstream about security and proper memory handling. As it was
> mentioned by paxteam and others as well. Like it is not just erroneous
> from the security point of view, but the whole concept of fixed address
> mmap is not correct.

The bug [1] referenced earlier contains a patch which allows again the
use of RANDMMAP (paxctl -R) with FF9. (At least it works for me and the
for the filer of the bug.) As mentioned earlier, this is a better
solution than pax-mark r.

Many thanks to zakalwe and pageexec for making this patch available so
quickly.

(I'm getting a very full /etc/portage/patches lately. Only this one is
related to hardened; the others are instead for silly things that
probably shouldn't be installed anyway.) At least this "wake up call"
had me test out some alternate browsers.

[1] https://bugs.gentoo.org/show_bug.cgi?id=396275

--
Regards,

wmw
 
Old 01-10-2012, 11:32 AM
Christian Apeltauer
 
Default hardened-sources & tp_smapi, firefox-9.0 install stucks

Am Sat, 31 Dec 2011 14:43:10 +0100
schrieb "Tóth Attila" <atoth@atoth.sote.hu>:

> Isn't it miserable to see, that as time is passing by, more and more
> important softwares (java, python, libreoffice, firefox) conflict with
> more and more PAX restrictions?

Hello hardened-list,
I would like to point out that I am still able to run icecat-9.0.1
without any pax feature disabled by patching the ebuild as shown by the
attached patch. Basically I applied the patch from Bug #396275 and
disabled both methodjit and tracejit. And now icecat (including
addons like noscript) runs without being pax-marked.
I am well aware of the warnings that the Javascript engine runs slower
without methodjit (by the way, why was that USE flag dropped?). I use
Javascript only when absolutely necessary, so I might not be the best
judge, but I don't see any noticeable impact on performance. Neither do
I use flash plugin or something like that, so neither can I say whether
flash will work without pax-marking.
May solution may not be workable for everybody. But I don't see a
reason why not to give it a try for ones like me who want a browser with
reasonable JS management (as provided by the noscript addon) but do not
need all the flashy extras. It should be up to the user to decide which
features to enable.
Best regards
Christian Apeltauer
 

Thread Tools




All times are GMT. The time now is 11:39 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org