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 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.
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 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/
>
> 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>
Attachment:
signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente