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  | Hardened    Hardened      | 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 XXX, 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.

Yes, i agree too.Target are users of any condition, that's because
Debian has a big impact everywhere.

> |
> |>[...]
> |>| 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!
> |>
> |>Ummmmmm, 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?
> 
> [...]

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, 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 and maintainer
> effort to implement this project.

Yes, PaX flags, etc....
I agree with you again, there's no need to separate the packages into
two different brands/branchs.

> These things need to be implemented as painlessly as possible.  The
> maintainers don't want to eat up twice as much mirror space just to
> support a security option.  I'm sure nobody wants to try and keep up
> with the maintainers and perpetuate said option; but you seem eager
> enough to do it yourselves, so I'll watch you get burned.

++i_agree_too;

> |
> |>RBAC I'll agree with, it can be a pain in the XXX 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/
> 
> RBAC == Role Based Access Control.  RSBAC and GRSecurity allow these
> schemes of access control to be implemented (SE uses the Flask model or
> something).

grSecurity has an specific implementation of RSBAC, anyway, grsec uses
MAC (Bell-LaPadula Mandatory Access Control, limited to 64 compartments)
and its special i. of 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).
> 
> Yes, you're on the ball here.

OK, so, finally, Do you agree with the things that i want to do at
"debian hardened"?

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!), 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.

Many thanks for your attention,
Cheers!
PS: Good night!
-- 
Lorenzo Hernandez Garcia-Hierro <lorenzo@gnu.org>

[ Post a follow-up to this message ]