Hi Steve!!
El sáb, 18-09-2004 a las 00:39, Steve Kemp escribió:
> On Fri, Sep 17, 2004 at 10:55:33PM +0200, Lorenzo Hernandez Garcia-Hierro wrote:
>
> > Yes.The `apt-get install hardened? was an example of something 100% easy
> > to use :D
>
> Unfortunately whilst easy to use is good the idea of rebuilding the
> packages presented so far isn't going to be easy to setup.
Yes, it will take long time to complete ALL the tree, but i have this
idea:
- We put first the patched GCC & Glibc packages (Steve, your 2 cents :D)
- We send an advice to the mailing-lists, we write a little "guideline"
for new development way, telling what the developer needs (and what he
must do) for start re-compiling the packages and making them "hardened".
> Either you end up rebuilding the archive with PaX + SSP + etc and
> distributing that, which then effectively becomes a fork, or you have
> to update the buildd network to include these things *by default*
> which is unlikely to happen in the short term.
Yes, that's what John said, the development must go in the main line,
it's not reliable to have two different trees of packages (except of the
kernels that will be just the ones making the difference, but packages
should go by default with PIE & SSP, etc).
> > I agree with you, the packages should be just one branch: main.
> > Al the packages should include the hardening features as they don't
> > interrupt with the software.
>
> That would be a worthy goal, and something I'd love to see. I
> suspect that without real testing and a lot of motivation it is
> unlikely to occur quickly though.
Yes...people should be concerned about security terms.
But, anyway, people gets concerned when somebody with a minimal
knowledge and a big 0day-asshole exploit messes up their machines.
And this happens really often nowadays.
> > > Now, if you're after creating SELinux, GRSecurity, and RSBAC policies,
> > > those can be controlled by boot time parameters to the kernel. Also, as
> > > long as they're off, there's no need for the user to install the policy.
> > > ~ Those are the types of things that can *feasibly* be made optional,
> > > because they don't require a recompile.
> >
> > Yes, i had the same idea, it's fine.
> > Recompile WOULDN'T BE NEEDED in any way.
>
> For those other things? No that is correct recompiling is not
> required, however for SELinux at least there must be the creation
> and distribution of policies. There was some discussion on this
> on debian-devel a while back, which I understood to be a lot of
> work.
SELinux seems to be in everybody's mind, but mine it's not :P
Why SELinux?
(and also why SHA-1! :D)
I think we can go in the way that John was talking about, giving
standard policies (if we need them) and using debconf to do the work
transparently of the user (but maybe asking something like: "Do you want
to set your own policy?" and "No, i want to have it working by now") and
making it easy.
Policies can be passed by appending some settings to the kernel cmd
line.
> Of course no policy is going to apply to all users, so there
> will be a bit of 'unsimpleness' involved for some.
Yeah, that's what i said :)
> > Yes, PaX flags, etc....
> > I agree with you again, there's no need to separate the packages into
> > two different brands/branchs.
>
> So practically, how do you see going forward?
I think we can do this:
Debian packages
-> Pool -> Hardened pool (temporal)
<---------------{if tested & finished}<---|
{if not hardened}->{start package hardening}^
We can start hardening the most important packages and making the kernel
packages (i've made many work on this, so, we can say that we need to
put our efforts in the packages).
The `main´ pool is the tree without hardened packages, we will move
packages (temporally) to the Hardened pool, and, after testing them, we
will replace the not-hardened with the hardened package.
No time loss and no performance of development loss.
After hardening the packages, thr hardened pool gets removed and the
only one remaining is the main pool.
What do you think about it?
I hope it will be the easiest way to do it.
I'm not a regex master, but, maybe we can derivate some work on our
stupid boxes :), we can try to make a little script to manage the
Makefiles, apply the needed patches and also everything we want, making
the work faster & (almost) automatic.
This is the little pseudo-code that we can get as dev model for it:
(check the sources)
-> get the ./src dir
-> analice the Makefile*
-> append -fstack-protector to CFLAGS.
-> apply ET_DYN stuff to LDFLAGS.
-> apply any other stuff to Makefiles.
-> If the package matches one of a
list, it will use some special patch:
ex. if ( $package == PHP) { apply (hardened-php)
patch; }
-> check for hunks, if there's one, send an advice message to the
developer or the tty in use.
-> create HARDENED file into the main dir for the sources,
insert:
- upstream author:
- "hardener" (this sounds bad :P)
- applied patches
- CFLAGS and LDFLAGS used.
- version of GCC,SSP and PIE used to compile.
-> end, close/unlock the files (for prevent other users or
processes to mess up our work).
-> et voilá!
-> start configuration->compilation.
-> dpkg-builpackage
-> echo "Have you moo'ed today?"
A bash script will be more easy to use.
Tell me if this is interesting, i can start something on the DH's cvs.
> > I think we can collaborate, and i'm really interested in working
> > together with the people of the debian project, also with the debian
> > security crew (Steve!),
>
> Assuming you mean me - I'm not associated with the Security people.
> Just to be clear ..
Cleared.
:)
> > so, just tell me , i'm waiting for hear a big
> > "We think it's great to work with it" and also i think my objectives are
> > worthy.
>
> I, personally, think that having the archive compiled with things
> like PaX/SSP is a good thing. I suspect that testing it and getting
> it all working is such a large effort that the buildds aren't going
> to switch overnight (if ever) and that changing this is going to be
> .. religious.
Maybe, many people think that God exists, but they haven't seen him (me
too) :P, i think we can work in it, and with a little effort from
everybody we can make this reliable.
> Practically I'm not sure what this means, the obvious course is
> to build and test things then report back 'hey it works'. Whether
> that will be sufficient to convince people remains to be seen -
> especially as things look like they are changing anyway.
Yes, i think so.
> (GCC seem to be moving with mudflap and not integrating SSP for
> example).
I see, anyway, SPP is tested and probed to be really stable, i think we
can continue trusting in it.
> Good night - 23:38 here, and I'm going to the pub!
Did you moo'ed in the pub?
(I don't know if the "girlfriend" package dependencies are available for
Woody, maybe for unstable and testing) :D.
Cheers!
--
Lorenzo Hernandez Garcia-Hierro <lorenzo@gnu.org>
Attachment:
signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente