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 <[EMAIL PROTECTED]>
signature.asc
Description: Esta parte del mensaje está firmada digitalmente