[Fwd: grsecurity Digest, Vol 42, Issue 1]

marty marty at goodoldmarty.com
Wed May 7 09:32:49 PDT 2008


For those of you that have invested serious time in HLFS I have forwarded todays
digest from GRsecurity.  The problem is clear, and HLFS is severely affected by
this. Please take a look and consider actions we can take to help, encourage,
beg, and plead, so we don't end up with an Ubuntu kernel in the future.
---------------------------------------------------------------------

Message: 1
Date: Wed, 07 May 2008 03:27:43 +0200
From: pageexec at freemail.hu
Subject: Re: [grsec] grsecurity 2.1.11 released for Linux
	2.4.36.2/2.6.24.4
To: grsecurity at grsecurity.net
Message-ID: <482121AF.32686.81DD3A7 at pageexec.freemail.hu>
Content-Type: text/plain; charset=US-ASCII

On 14 Apr 2008 at 21:07, Brad Spengler wrote:

> It is not clear if the PaX Team will be able to continue supporting 
> future versions of the 2.6 kernels, given their rapid rate of release 
> and the incredible amount of work that goes into porting such a 
> low-level enhancement to the kernel (especially now in view of the 
> reworking of the i386/x86-64 trees). It may be necessary that grsecurity 
> instead track the Ubuntu LTS kernel so that users can have a stable 
> kernel with up-to-date security fixes. I will update this page when a 
> final decision has been reached.
> 
> In the meantime, please email pageexec at freemail.hu and let him know how 
> much you appreciate the hard work he has put in for the past 8 years. 
> The accomplishments of the PaX Team have extended far beyond just Linux, 
> and have today found their way into all mainstream operating systems.

now that i released a new test patch for 2.6.25.1, i'd like to address
the above.

first of all, thank you all who emailed me during this time, i hope
you'll forgive me for not responding to everyone individually, it'd
take too much time and repetition, so i'd rather answer here. if
there're questions left unanswered, just ask again (preferably in
public).

as spender said, there're several factors that make the continued
maintenance of PaX harder than necessary or maybe even unfeasible
given the circumstances.

for me the most important one is my free time i can spend on this
project, which has always been a delicate balance between family
and friends and other things that needed my attention. as long as
this time was enough to cover the necessary work needed for a forward
port, i did the work.

things have changed on both fronts though in that both my time i
can spend on this will soon decrease and the effort needed has
increased quite a lot as well with the inevitable consequence that
the development (or let's just stick to maintenance) of PaX have
slowed to a crawl. so lest things change for the better, future
releases may not happen at all or rather irregularly.

many of you asked how things can change for the better. given the
above, there're a few ways but frankly, i don't think any of it is
realistic.

one way is to increase the time spent on PaX. this can come from
either me or someone else. for me it's pretty much not possible
because if there's anything i want to spend less and less my time
on then it's everything computer security related. it was fun and
interesting at the turn of the millennium, but not anymore. so no
amount of funding or moral support will help here i'm afraid. on
the other hand the door is open for other adventurous souls to take
over, although i doubt anyone will show up. note that helping with
a few chunks or trivial rejects is of little help to me since, well,
i can do that easily too. the really big work is always related to
core changes done in PaX and porting those requires very deep
understanding of both the kernel and PaX (and a lot of time to debug
the inevitable bugs).

the other way is to decrease the effort needed for a forward port.
this in turn would require a change in the current linux development
model which is not going to happen anytime soon. one could also track
the vanilla tree more often/closely, but then we're back at the free
time problem (most of which would be a complete waste since as end
users you're really interested in the patch that works with a release,
not arbitrary git snapshots).

so there you have it, i know it looks rather bleak, but c'est la vie.

cheers,
  PaX Team



------------------------------

Message: 2
Date: Wed, 7 May 2008 12:20:44 +0200
From: Marcel Meyer <meyerm at fs.tum.de>
Subject: Re: [grsec] grsecurity 2.1.11 released for Linux
	2.4.36.2/2.6.24.4
To: grsecurity at grsecurity.net
Message-ID: <200805071220.45031.meyerm at fs.tum.de>
Content-Type: text/plain; charset="iso-8859-1"

Hi pageexec, hi Brad and everyone else involved,


first of all let me say, how sad this is but that I understand you're
struggleing. So I don't want to sound selfish and ruthless, but I'm really
concerned, so I dare to ask nontheless. Please don't take it personally.
Your work was and is much appreciated!

Am Mittwoch, 7. Mai 2008 schrieb pageexec at freemail.hu:
> so lest things change for the better, future releases may not happen at 
> all or rather irregularly. 
You said neither small-project-help nor donating would help anything. So not
even getting enough interested companies together to fund your work would
be a solution. In the long run we may reckon that you will no longer
pushing PaX forward. And someone else taking over is, as you already said,
not very likely. Kernel work itself and especially security related stuff
isn't simply anything you can learn along the way as coding for a desktop
environment.

But when looking on the administrators: what alternatives do we have when we
need/want to use Linux on important servers? Looking on the 4 big security
related Linuxkernel-projects doesn't seem to offer a solution. SELinux
(which is a pita due to it's complexity and error-proneness while
configuring) and AppArmor only offer protection for a couple of objects
(files, sockets, etc.). RSBAC and grSecurity both rely on PaX for memory
protection etc.

Staying with an old kernel for a long time is of no use. Especially since
the virtualisation techniques are getting updates each day and on the other
hand these are getting more and more important again. Is there anything
comparable (which I disbelieve since after creating an internal
presentation about the kernel based security enhancements within the last
years I realised how much came out of your project! Congratulations :-) )
which can be used as a drop-in when PaX really stops adapting to new
kernels? Or what can be the way to go for us paranoid folks which is only
sleeping well because you abstained from the same? ;-)


Again thank you very, very much for your awesome work!

Marcel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url :
http://grsecurity.net/pipermail/grsecurity/attachments/20080507/92f354bc/attachment-0001.pgp


------------------------------

Message: 3
Date: Wed, 7 May 2008 15:51:34 +0200
From: Bj?rn Schl?gl <mastamind at quantentunnel.de>
Subject: [grsec] PAX_PAGEEXEC for MVIAC7
To: grsecurity at grsecurity.net
Message-ID: <200805071551.39961.mastamind at quantentunnel.de>
Content-Type: text/plain; charset="utf-8"

hi!

the list of dependencies for PAX_PAGEEXEC misses MVIAC7. i use a patch to the
grsecurity patch to get pageexec support for my via c7.

regards,
bj?rn

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2.1.11-2.6.24.6-200805061854-via-c7.patch
Type: text/x-diff
Size: 872 bytes
Desc: not available
Url :
http://grsecurity.net/pipermail/grsecurity/attachments/20080507/a5afb776/attachment-0001.bin


------------------------------

Message: 4
Date: Wed, 07 May 2008 10:19:01 -0500
From: Heiko Zuerker <heiko at zuerker.org>
Subject: Re: [grsec] grsecurity 2.1.11 released for Linux
	2.4.36.2/2.6.24.4
To: grsecurity at grsecurity.net
Message-ID: <20080507101901.12547ct48ajc898o at www.home.zuerker.org>
Content-Type: text/plain;	charset=ISO-8859-1;	DelSp="Yes";
	format="flowed"

We didn't talk about what it means for grsec if the PAX development
comes to a halt.
Brad, do you already have a game plan for this?

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org



Quoting pageexec at freemail.hu:

> On 14 Apr 2008 at 21:07, Brad Spengler wrote:
>
>> It is not clear if the PaX Team will be able to continue supporting
>> future versions of the 2.6 kernels, given their rapid rate of release
>> and the incredible amount of work that goes into porting such a
>> low-level enhancement to the kernel (especially now in view of the
>> reworking of the i386/x86-64 trees). It may be necessary that grsecurity
>> instead track the Ubuntu LTS kernel so that users can have a stable
>> kernel with up-to-date security fixes. I will update this page when a
>> final decision has been reached.
>>
>> In the meantime, please email pageexec at freemail.hu and let him know how
>> much you appreciate the hard work he has put in for the past 8 years.
>> The accomplishments of the PaX Team have extended far beyond just Linux,
>> and have today found their way into all mainstream operating systems.
>
> now that i released a new test patch for 2.6.25.1, i'd like to address
> the above.
>
> first of all, thank you all who emailed me during this time, i hope
> you'll forgive me for not responding to everyone individually, it'd
> take too much time and repetition, so i'd rather answer here. if
> there're questions left unanswered, just ask again (preferably in
> public).
>
> as spender said, there're several factors that make the continued
> maintenance of PaX harder than necessary or maybe even unfeasible
> given the circumstances.
>
> for me the most important one is my free time i can spend on this
> project, which has always been a delicate balance between family
> and friends and other things that needed my attention. as long as
> this time was enough to cover the necessary work needed for a forward
> port, i did the work.
>
> things have changed on both fronts though in that both my time i
> can spend on this will soon decrease and the effort needed has
> increased quite a lot as well with the inevitable consequence that
> the development (or let's just stick to maintenance) of PaX have
> slowed to a crawl. so lest things change for the better, future
> releases may not happen at all or rather irregularly.
>
> many of you asked how things can change for the better. given the
> above, there're a few ways but frankly, i don't think any of it is
> realistic.
>
> one way is to increase the time spent on PaX. this can come from
> either me or someone else. for me it's pretty much not possible
> because if there's anything i want to spend less and less my time
> on then it's everything computer security related. it was fun and
> interesting at the turn of the millennium, but not anymore. so no
> amount of funding or moral support will help here i'm afraid. on
> the other hand the door is open for other adventurous souls to take
> over, although i doubt anyone will show up. note that helping with
> a few chunks or trivial rejects is of little help to me since, well,
> i can do that easily too. the really big work is always related to
> core changes done in PaX and porting those requires very deep
> understanding of both the kernel and PaX (and a lot of time to debug
> the inevitable bugs).
>
> the other way is to decrease the effort needed for a forward port.
> this in turn would require a change in the current linux development
> model which is not going to happen anytime soon. one could also track
> the vanilla tree more often/closely, but then we're back at the free
> time problem (most of which would be a complete waste since as end
> users you're really interested in the patch that works with a release,
> not arbitrary git snapshots).
>
> so there you have it, i know it looks rather bleak, but c'est la vie.
>
> cheers,
>   PaX Team
>
> _______________________________________________
> grsecurity mailing list
> grsecurity at grsecurity.net
> http://grsecurity.net/cgi-bin/mailman/listinfo/grsecurity
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



------------------------------

_______________________________________________
grsecurity mailing list
grsecurity at grsecurity.net
http://grsecurity.net/cgi-bin/mailman/listinfo/grsecurity


End of grsecurity Digest, Vol 42, Issue 1
*****************************************



-- 
Building a better mousetrap only results in better mice. C. Darwin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20080507/dafc2ece/attachment.sig>


More information about the hlfs-dev mailing list