Re: Debian Hardened project (question about use of the Debian trademark)
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
Re: Debian Hardened project (question about use of the Debian trademark)
Hi John!
El vie, 17-09-2004 a las 21:51, John Richard Moser escribió:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lorenzo Hernandez Garcia-Hierro wrote:
| Hi John,
|
| El vie, 17-09-2004 a las 19:04, John Richard Moser escribió:
|
|-BEGIN PGP SIGNED MESSAGE-
|Hash: SHA1
|
|
|
|Lorenzo Hernandez Garcia-Hierro wrote:
|| Hi,
||
|
|[...]
|
[...]
|I prefer directly hardening Debian with things that don't get in the way
|of the user. That's what I was going on about a month ago with PaX (I'm
|still working with that, just waiting until after Sarge). As long as
|the user doesn't have to see it, it can and I think should go into
|mainline Debian.
|
|
| Debian Hardened is not a Debian-based distro, i said that it is a
| hardened tree of packages and kernels that should replace (with user
| election or by default, for example asking the user during the
| installation if he wants to have extra security or if it will be used
| for critical uses).
| I think the same as you, it must go in the Debian mainline.
Yes yes I understand you're a subproject.
Nice :P
The kernel can be elective, but some of the work that gets done will
require either a separate copy of the entire debian tree, or will
require that the changes go into mainline. Building binaries with SSP
and PIE is like building binaries using gcc 2.95 or gcc 3.4: the
decision won't directly affect the users' experience, and it can't be
made an option to the user without a lot of extra storage space on the
mirrors and a lot of work maintainer side.
I agree with you, SSP PIE are not a problem in the system, and also PaX
flags can work out of the box with a patched kernel but they don't do
anything when the kernel hasn't PaX in it.
|
|Debian.
| -
| | |
| ^ ^
| Kernel packages Software Packages.
| --|--- --|-
| Not Hardened | HardenedHardened | Not hardened.
| --
| \apt-get install harden /
| \ debian-hardened /
|\ /
|| *KISS*|
||Keep it simple,stupid|
|\-/
|
|
Debian
|- Kernels
||- Hardened (PaX enabled, SELinux enforcing, etc)
||- Non-Hardened
|- Maintenance
||- Compiler used
|||- Options used
- Optimizations
|- -O2
- Security options
|- -fstack-protector
|- -fpie
||- Packaging
|||- Mirrors
SELinux? I think there are better solutions than it, possibly i'm just
obssesed with its alternatives ;-)
I agree with your idea, and i'm going in the same way.
We have the same goals basically; but I don't think that for most of
this there is room for an 'apt-get install hardened' or whatever. The
changes are too integral to be covered by a handfull of packages; you
would need an entire mirror of all Debian packages with all hardening
features.
Yes.The `apt-get install hardened´ was an example of something 100% easy
to use :D
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.
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.
|My point here is, you mention advanced users and sysadmins; but I'm
|focused on people who are too stupid to remember how to save a document
|in MS Word in RTF format instead of .doc.
|
|
| Look above.
| People is not stupid, my father is not stupid because he doesn't know
| which Debian means...people want to do simply their things in their
| live, that's usability and we can't make people start learning, for
| example, LaTeX,TeX,whatever you want... if they only want to write poems
| on a page, or teach maths to their children.
|
You need to get out more; a *lot* of people are stupid. ;)
s/lot/LOTS/ :)
Many of them are in the top of this society, the truth is NOT out
there, just type something like this in your terminal {C+m+f Fun mode
on}: lynx http://www.***.com/search?q=our+stolen+(l)unix+code
Don't go on the assumption that people know wtf they're doing. I know
wtf I'm doing. I could rebuild a Debian Sarge installation as it exists
today with all hardening features. It's still a pain in the ass, and I
don't want to be bothered. Even when the target isn't an idiot, he may
still
Re: Debian Hardened project (question about use of the Debian trademark)
Hi John,
El sáb, 18-09-2004 a las 00:20, John Richard Moser escribió:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lorenzo Hernandez Garcia-Hierro wrote:
[...]
Good, at least you understand that :)
|
|Yes and then the program halts and gets SIGABRT. Do you not know what a
|DoS attack is?
|
|[...]
|
|
| Duty of Shame ?
| OK, leaving the Fun Mode off...
| (here, Spain, it's 23:00 and 'm tired, i've started the school this week
| and its the last course to get in the high school, two years more and
| then the university...i must work harder! ;-D )
| ProPolice sends messages to /var/log/messages and also to the last
| 4kbytes of dmesg, or whatever you have selected to be used by syslogd.
| The idea is simple: ANY package will be more secure compiled with PIE
| SSP/PPolice than compiled itself without any other extension (in this
| case, security related).
|
Yes but the point is that while you deflect the intrusion, I can still
rape the program raw and continually force it to terminate.
Also, in cases such as Apache, which populates the system with fork()s
of itself, the address space isn't rerandomized; the SSP canary isn't
rerandomized; and overall it's very difficult to prevent an attacker
from rabidly drilling into the skin of these daemons and going until he
hits both of these. This can be done in probably an hour or so. In
these events, SSP and ASLR become like passwords: They deflect attacks
nicely, but can be directly exploited by an attacker with enough time.
Imagine having a vulnerable Xchat too. Attacker can't come in; but you
can NOT stop some jackass from just {DCC SEND @*Y^! 1
! ! ! ! ! ! ! } and taking you down whenever he wants.
It's less pressing when you have these; but you do still need to get up
to date with security patches.
Yes, you're right, anyway, ETDYN, etc, there's life out of PIE SSP.
In words of Alan Cox...Obscurity does not bring security ;-)
I must go to sleep...good night!
Cheers,
PS:We will continue with this tomorrow,maybe, but i want to know what do
you think about DH, and also, if you would mind collaborating with it.
I'm having no replies from the Debian Security guys (referring to this
mail, i'll send an email to Steve tomorrow, possibly he is busy or out
of office), i would like to talk with jfs, he is spanish and i think
we can talk clearly and then communicate the decisions in the best way.
--
Lorenzo Hernandez Garcia-Hierro [EMAIL PROTECTED]
signature.asc
Description: Esta parte del mensaje está firmada digitalmente
Re: Debian Hardened project (question about use of the Debian trademark)
Hi John,
El vie, 17-09-2004 a las 19:04, John Richard Moser escribió:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lorenzo Hernandez Garcia-Hierro wrote:
| Hi,
|
[...]
| Debian Hardened is like Debian Junior, and the rest of subprojects.
| *We* must provide the best (and the easiest) way to harden Debian for
| advanced users, sysadmins or just people that want a really *more*
| secure environment than the common one, that does not need to be
| insecure but it will be more unsafe if you compare it with the same
| system but hardened.
I prefer directly hardening Debian with things that don't get in the way
of the user. That's what I was going on about a month ago with PaX (I'm
still working with that, just waiting until after Sarge). As long as
the user doesn't have to see it, it can and I think should go into
mainline Debian.
Debian Hardened is not a Debian-based distro, i said that it is a
hardened tree of packages and kernels that should replace (with user
election or by default, for example asking the user during the
installation if he wants to have extra security or if it will be used
for critical uses).
I think the same as you, it must go in the Debian mainline.
Debian.
-
| |
^ ^
Kernel packages Software Packages.
--|--- --|-
Not Hardened | HardenedHardened | Not hardened.
--
\apt-get install harden /
\ debian-hardened /
\ /
| *KISS*|
|Keep it simple,stupid|
\-/
My point here is, you mention advanced users and sysadmins; but I'm
focused on people who are too stupid to remember how to save a document
in MS Word in RTF format instead of .doc.
Look above.
People is not stupid, my father is not stupid because he doesn't know
which Debian means...people want to do simply their things in their
live, that's usability and we can't make people start learning, for
example, LaTeX,TeX,whatever you want... if they only want to write poems
on a page, or teach maths to their children.
[...]
| if
| you a hardened binary (+SSP/ProPOlice and a library to trace the BOF
| conditions) in a hardened environment (hardened kernel and RBAC/RSBAC
| policies) it will be not dangerous as having a simple Debian!
Umm, update anyway dude. It's still a DoS attack.
Buffer Overflow conditions in the stack will be stopped by ProPolice
(__guard ...).
| We can start asking ourselves about Why not making Debian hardened
| directly?, we need to respect the freedom of choice and also, a normal
| user wouldn't want to use RBAC...or not?
Some technologies, like SSP and PIE, have to be compiled directly into
the program. Most users would chose not to recompile their system. I
believe that nobody would be particularly upset if their system was more
secure *as* *long* *as* it does not become visible to them. If it looks
no different, I think the 'lesser of two evils' here would be to be
secure by default, and let the user who for some odd reason wants to be
a target to rebuild.
Yes, ProPolice/SSP is a GCC extension.
Rebuild?
Ok, i'm a Gentoo user, mea culpa :P, but i thought that i din't say to
recompile packages, i said make binary packages in a different branch.
(Again, the theme of the graphic i wrote above) .
RBAC I'll agree with, it can be a pain in the ass and can change the way
an administrator has to interact with the system, which can become
confusing to the user. GRSecurity with active ACLs or an active SELinux
shouldn't be on by default; but they can easily be options which the
user can activate with a debconf program.
s/RBAC/RSBAC/
Yes, i agree with you.RSBAC is not usable for everybody.
But debconf can make a simple dialog asking for RBAC (grSecurity RSBAC
implementation in this case) password, then it starts -L
/var/log/rbac (or ${RBAC_LOG} for use it by debconf and asking what path
is the right one for the log).
Then it starts the enginerbac learninget voilá!
Cheers!
--
Lorenzo Hernandez Garcia-Hierro [EMAIL PROTECTED]
signature.asc
Description: Esta parte del mensaje está firmada digitalmente
Re: Debian Hardened project (question about use of the Debian trademark)
Hi, El mié, 15-09-2004 a las 09:35, Sven Luther escribió: On Tue, Sep 14, 2004 at 04:40:53PM +0100, Martin Michlmayr wrote: * Lorenzo Hernandez Garcia-Hierro [EMAIL PROTECTED] [2004-09-08 16:26]: I want to know if i can use the trademark Debian on the name of a project that i've started , Debian Hardened which i want to see as an official Debian sup-project. I personally feel that this name has the same problems that Trusted Debian has - it suggests that normal Debian is not secure. In any case, I think you should post your question to debian-project rather than -legal since -project is more appropriate and might get more feedback. Notice that unlike the Trusted Debian case, Lorenzo seem to be willing for it to be an officially recognized sub project, like the custom debians are. yeah, That's it! Adamantix (old Trusted Debian) is a different distro (and also i have good relationship with many of its developers, Peter for example). Debian Hardened is like Debian Junior, and the rest of subprojects. *We* must provide the best (and the easiest) way to harden Debian for advanced users, sysadmins or just people that want a really *more* secure environment than the common one, that does not need to be insecure but it will be more unsafe if you compare it with the same system but hardened.As a good example...you can forget to update your Bind9 named daemon 'cos somebody announced a new BOF in its code, but if you a hardened binary (+SSP/ProPOlice and a library to trace the BOF conditions) in a hardened environment (hardened kernel and RBAC/RSBAC policies) it will be not dangerous as having a simple Debian! That's the difference. We can start asking ourselves about Why not making Debian hardened directly?, we need to respect the freedom of choice and also, a normal user wouldn't want to use RBAC...or not? If somebody has read the TRNG tasks, on SF.net, it's related with some enhancements in the LEP (Linux Entropy Pool) using a TRNG device, that would make 99.9% (just for be paranoid, at the momment no body has demonstrated that the atomic decay is not unpredictable) unpredictable random numbers to be used within the LEP (/dev/random) making an user-space daemon and modifying random.c to take care of the TRNG (some of this work is not completed, but i've started doing some dirty hacks to random.c). Thanks in advance, Cheers. -- Lorenzo Hernandez Garcia-Hierro [EMAIL PROTECTED] PS: If i want to colaborate to the Debian project that's because i think i must give something back to the community that developed this fantastic distro! signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: Debian Hardened project (question about use of the Debian trademark)
Hi Martin, El mar, 14-09-2004 a las 17:40, Martin Michlmayr escribió: * Lorenzo Hernandez Garcia-Hierro [EMAIL PROTECTED] [2004-09-08 16:26]: I want to know if i can use the trademark Debian on the name of a project that i've started , Debian Hardened which i want to see as an official Debian sup-project. I personally feel that this name has the same problems that Trusted Debian has - it suggests that normal Debian is not secure. In any case, I think you should post your question to debian-project rather than -legal since -project is more appropriate and might get more feedback. A normal Debian is secure, depending on how the sysadmin works with the packages and how he confgiures them. But, if you have, for example, ProPolice/SSP compiled packages, there wouldn't be anyway to exploit a buffer overflow condition in the package. That's the same with kernel packages...you can choose a better secure kernel or a simple one, the difference is just what you want to choose: secure or not secure as the other... Security stays OK until somebody breaks it, and you can't predict when it will happen (and also you can't predict how it will happen!). I want to see Debian Hardened as an official Debian subproject, it's not a better, more secure un-official version of Debian, it's just a hardened tree of official Debian packafes for official Debian versions! (Also i'm working with a friend to make some enhacements for the Linux entropy pool engine, using an external TRNG device). Cheers, -- Lorenzo Hernandez Garcia-Hierro [EMAIL PROTECTED] signature.asc Description: Esta parte del mensaje está firmada digitalmente
Debian Hardened project (question about use of the Debian trademark)
Hi, I want to know if i can use the trademark Debian on the name of a project that i've started , Debian Hardened which i want to see as an official Debian sup-project. The website is at http://sourceforge.net/projects/debianhardened Thanks in advance, -- Lorenzo Hernandez Garcia-Hierro [EMAIL PROTECTED] signature.asc Description: Esta parte del mensaje está firmada digitalmente
