| 1 |
On Friday 05 September 2003 10:13, Jan Krueger wrote: |
| 2 |
> a guide for portage developers how to make sure the things installed are |
| 3 |
> secure. Just like |
| 4 |
> http://www.openbsd.org/porting.html#Security |
| 5 |
|
| 6 |
we dont have one and i dont believe there are plans for one ... again, the |
| 7 |
people who would be writing it are the gentoo-hardened team but i havent seen |
| 8 |
any mentions of it on the hardened list ... |
| 9 |
|
| 10 |
> Thats your point of view. |
| 11 |
|
| 12 |
not really ... the performance hit is not acceptable |
| 13 |
|
| 14 |
> No, it should not. Site Security doesnt stop at the ebuild maintainer. |
| 15 |
> I, as a potential user of "trusted gentoo", would like to have a way to |
| 16 |
> verify the work of the developer. |
| 17 |
|
| 18 |
then verify it ... either you trust gentoo developers or you dont ... |
| 19 |
|
| 20 |
> I might want to use 3rd party ebuilds, commercial ebuilds, special |
| 21 |
> super-hardened ebuild not in normal portage |
| 22 |
> tree, i might have requirement complety different from what the developer |
| 23 |
> thought. |
| 24 |
|
| 25 |
like i said this is were the special util or pkg could be utilized that would |
| 26 |
do this kind of security scan ... basically it is used whenever the user |
| 27 |
wants to do that kind of research. but again, no such think (afaik) exists. |
| 28 |
|
| 29 |
> And also it is impossible to bring all those ebuild to the high |
| 30 |
> security standard i mention here, so i should have the possibility to |
| 31 |
> verify at emerge time. So, instead of "esecurity_check" it should be a |
| 32 |
> portage feature that i can switch on. |
| 33 |
|
| 34 |
in that vein, no work has been done |
| 35 |
|
| 36 |
> After every unpack or even building |
| 37 |
> the image, just before installation, i would like to see what security |
| 38 |
> impacts the package might have in its source or how many suid progs it |
| 39 |
> wants to install or whatever. And if i say so, the ebuild should not |
| 40 |
> install as soon as the scanners detect that the installed software would |
| 41 |
> not conform to my requirements (that i would have to define in make.conf). |
| 42 |
|
| 43 |
talk to hardened ... there is already work to trim out all (if possible) suid |
| 44 |
binaries ... |
| 45 |
|
| 46 |
> According to whats written on the project side the issue i bring up here is |
| 47 |
> not (yet) covered. a secure box can always be compromised by installing |
| 48 |
> insecure software. So installing secure software (only) should be made easy |
| 49 |
> and verifyable. As portage is responsible for installing software on our |
| 50 |
> gentoo machines it should support us in developing and installing secure |
| 51 |
> software. |
| 52 |
|
| 53 |
well, there are instances where this is not true, but lets not bother mincing |
| 54 |
words on a moot point ;) |
| 55 |
|
| 56 |
> It is dumb (no offense meant) to believe the ebuild-maintainer knows about |
| 57 |
> and respects the local Site Security Requirements. It is dumb to believe |
| 58 |
> every administrator or user is a security expert and can audit each |
| 59 |
> software package before installation. |
| 60 |
|
| 61 |
agreed |
| 62 |
|
| 63 |
but all in all, i'd suggest taking this thread to the hardened list. the |
| 64 |
people who are on that list make security their #1 focus. you'd get a very |
| 65 |
different reception (probably more useful input) than here on -dev. |
| 66 |
-mike |
Archives