Re: Debian Hardened project (question about use of the Debian trademark)
On Sat, Sep 18, 2004 at 01:51:53PM +0200, Lorenzo Hernandez Garcia-Hierro wrote:
- 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.
'must' is a strong term.
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 going to be far harder than you think.
Right now there is no standard way to pass extra options
down to the packages as they are being compiled, this is why
packages like athlon-builder, and pentium-builder exist as
wrappers round GCC. They are suboptimal.
It might be a better approach to start out by constructing something
which would allow *arbitary* options to be passed through to compilers,
linkers regardless of the source package.
However this will likely involve patching all the packages, and
trying to get those changes accepted upstream might be problematic.
(I wonder how Gentoo manage their 'USE' flags wrt upstream?)
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.
Sounds like it would be interesting, but I suspect you'd only
discover how difficult it is after trying. (Not that I'm trying
to put you off, its just that the packages we have aren't all
buildable easily - some use ./configure, others use bizarre
Makefiles and yet others use imake).
Tell me if this is interesting, i can start something on the DH's cvs.
It sounds interesting .. I reckon that short-term you'd be better
off using wrappers around ld, g++, gcc, etc. But having a general
mechanism for passing in additional arbitary flags would be useful
for lots of things - from insane optimizations, to adding in support
for different protection models.
Steve
--
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, if
Re: Debian Hardened project (question about use of the Debian trademark)
-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. 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. | | 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 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. 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. |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. ;) 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 prefer to have the work done for him; otherwise he'd be using LFS. | |[...] || 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 ...). | Yes and then the program halts and gets SIGABRT. Do you not know what a DoS attack is? [...] | | | 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) . | I don't believe that forking a Debian package for these protections is appropriate. They don't harm anything; anything that they do harm of course you can't protect anyway. There's no point in separating the two bases, and no point in wasting tons of mirror space
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)
-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.
|
[...]
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFBS2MUhDd4aOud5P8RArSMAJ9YB5zV2Ps2vGWrdxrRyV17KO6teACfc6bF
mzY9u1B4AGpNuAgL34V2/B4=
=iR76
-END PGP SIGNATURE-
Re: Debian Hardened project (question about use of the Debian trademark)
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. 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. 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. 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. Of course no policy is going to apply to all users, so there will be a bit of 'unsimpleness' involved for some. 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 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 .. 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. 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. (GCC seem to be moving with mudflap and not integrating SSP for example). PS: Good night! Good night - 23:38 here, and I'm going to the pub! Steve --
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)
-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. 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. [...] | 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. | 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. 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. [...] | Thanks in advance, | Cheers. - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBSxkjhDd4aOud5P8RAhrgAKCCLpcqdv3zxwcG5Fo8rDPGOvLLEwCfc0Wo 4ZO3r5ScbvtWKOSqQP9uNEg= =Yl7W -END PGP SIGNATURE-
Re: Debian Hardened project (question about use of the Debian trademark)
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. Friendly, Sven Luther
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
Re: Debian Hardened project (question about use of the Debian trademark)
Hi Lorenzo, Martin, lists, Lorenzo Hernandez Garcia-Hierro wrote: :: 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. Trully. A few weeks ago, a friend of mine was talking to our Debian User Group and he told that you can setup your system in a way that it could be more secure than OpenBSD. :) I'm not here to talk about which system is the most secure, but of course, that are lot of things to consider and fine tunning when we talk about security. :: 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... Ok! Why I quote my friend? Because he is starting a project similar with Debian Hardened. :: 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!). Trully. :) :: 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! Thinking on my friend's project and in Debian Hardened, I was wondering if we could joing Debian Security and develop all this stuff there? I can say that the idea of my friend is create a kind of documentation, comparing security tools, creating benchmarks, making tests and packages, with the objective of making Sys/Net Admin life easier (and more secure). In the last months I'm trying to understand how can a person joing the Debian Security Team and help them on packages and machines, I'm not sure, but if I understand the Lorenzo idea, we can work together doing a kind of auditing and developing packages, maybe we should put it in another tree like proposed-security or security-enhanced., in manner that doesn't sounds like debian is insecure or less secure. Doing this, we have a sub project with focus on Security, official. Well, it is just a thought! :) Best Regards, -- // // Felipe Augusto van de Wiel (faw) // [EMAIL PROTECTED] // http://www.cathedrallabs.org / // GUD-PR / DUG-PR || http://www.debian-pr.org // GUD-BR / DUG-BR || http://www.debian-br.org // Debian Project || http://www.debian.org/ //
Re: Debian Hardened project (question about use of the Debian trademark)
* 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. -- Martin Michlmayr [EMAIL PROTECTED]
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
