Re: grsecurity-1.99cvs with parisc-linux-2.4.20pa22 patch [becomes security software discussion]
hello,
humm, sorry, but this was (as i understand it) merely a proof of concept
that such work _can_ be done on special architectures.
the current situation with linux hardening patches like openwall, lids,
grsecurity, rsbac and the like is that they give a sh** about non-intel:
take a vanilla kernel from kernel.org
patch it and compile it on intel.
maybe sparc and sparc64 is already supported.
mabye alpha too.
maybe work is underway to address ia64 also.
but parisc is "new in town" compared to the work being done in this area.
i don`t know how far the lids people get with their patches.
last year, with the early 2.4.* there was no statement about this.
but Brad and his team are evolving one of the first "pariscable"
security hardening packages for the linux kernel on our platform.
something the AIX and HPUX people already perform with Trusted Path and
HP/9000 IDS packages, some very good (*commercial*) intrusion detection
and host protection software.
my idea is to bring such enhancements into our parisc boxes.
i know, there is still pretty much work todo, mainly in the stack and
program execution (fs/exec.c, mm.h, ...) tree.
Brad and his team are working on standard vanilla 2.4.* kernels from kernel.org.
I don`t know if it would be possible to "create" a parisc stream for the
development of grsecurity on the parisc-linux 2.4.*-pa** kernel trees.
but anyway, what i`m going to do is to watch the development of the
grsecurity patch in the mainstream kernel.org linux kernel patches, try
to adapt as many of it`s platform independent and platform dependent
features (with dev@grsecurity.net`s help) and to try to set up one of
the first "hardened" debian-hppa linux machines.
and if this is going well, i assume we could pick around a little bit in
the debian package system and create various kernel packages aside from
the "normal" debian-hppa kernels.
this would be sufficient for me in the short run :-)
of course, i also should put it into gzip format... sorry, forgot that.
linux2420pa22-grsec199cvs-patch_FINAL_gzipped.TXT.gz
> And todays news with the mysql worm wreaking havoc...
i don`t think, things like an application weakness can be _prevented_ by
intrusion detection and host protection software.
basically, what people like the lids staff and the grsecurity folks try
to achieve are two things:
prevent "reconnaissance" via stealthing characteristics of the network
and the local system behaviour
prevent "tampering" with the system, e.g. forcing chroots and/or root
hacks into a more non-dangerous role, because the /bin /sbin /usr/bin
/usr/sbin /lib /usr/lib and /boot and /kernel and stuff like that is
protected in the kernel.
which is altogether all but secure since we learned about kernel bugs in OpenBSD. *sigh*. But this is another story :-)
>
> > here is the patch:
> >
> > https://nikita.ath.cx/users/pappy/grsec/199_cvs_pappy/linux2420pa22-grsec199cvs-patch.txt
>
> Issues with the patch:
> o it's 1.8MB - at this size, gzipping would yeild good benefits.
your wish has been granted.
>
> o most of this patch is arch independent and touches nearly every
> part of the kernel. Given the number of arches the patch has support
> for, there must be some reason why upstream hasn't accepted this yet.
> Anyone know why not?
i believe, the 2.4.x Linux Kernel with this modularized concept of
security modules would not work with many of these patches we are
talking about here. not yet working.
>
> o And lastly, someone needs to remove extraneous things that shouldn't
> go in the parisc CVS:
> - linux/Makefile,
> - linux/*.orig (several of these)
> - linux/arch/i386 ia64 cris m68k etc
of course these are things we should consider when trying to put the
patches and the kernel sources and the kernel images packetized on a debian mirror.
what i want to say is:
the grsecurity patch (and the lids patch) is very important for people
like me who are trying to protect machines. but it is very very
unimportant for 99.99 percent of parisc-linux CVS junkies.
so, it is not necessary (imho) to reserve an extra CVS hotel room and
let the patch check in.
i would prefer working an a solution where the patch can walk in as a debian-hppa source kernel and cooked kernel package to give people a "feeling" what can be done on this platform to secure webservers, mail servers, demilitarized hosts like DNS and PROXY servers and such things.
if you want the patch (and other security patches) to go into a
paric-linux cvs tree and in the future to be mergeable into
parisc-linux/cvs pa** parisc kernels, i would accept that solution,
because in the long run it is the better way to get something going in a
cvs instead of letting it lying around on some dudes workstation at home
:-), but it would require that we talk to Brad Spengler about how he wants
the thing going, because he is doing the main work and i am just
crippling around in the /arch/parisc tree and apply those default kernel diffs to make them work with our bits.
> thanks,
> grant
good afternoon from germany,
it is cold, wet and the sun has not been shining for days
looks like i got my winter depression at hand
bye,
Alex
>
>
> --
> To UNSUBSCRIBE, email to debian-hppa-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
--
Nothing so needs reforming as other people's habits.
-- Mark Twain
pub 1024/05E1A80C 2001/12/16 Alexander Gabert (http://nikita.ath.cx) <pappy@nikita.ath.cx>
Key fingerprint = 2D 84 B0 CB F5 67 8A 22 8D 37 6E 6B 8A 3B 7F D6 05 E1 A8 0C
Reply to: