| 1 |
On Friday 05 September 2003 04:17, Mike Frysinger wrote: |
| 2 |
> On Thursday 04 September 2003 21:10, Jan Krueger wrote: |
| 3 |
> > Hi, |
| 4 |
> > |
| 5 |
> > is there a guide like |
| 6 |
> > http://www.openbsd.org/porting.html#Security |
| 7 |
> > in progress? available? |
| 8 |
> |
| 9 |
> uhh we have gentoo-hardened ... not sure what you're asking about ... |
| 10 |
I am asking about something like |
| 11 |
http://www.openbsd.org/porting.html#Security |
| 12 |
|
| 13 |
a guide for portage developers how to make sure the things installed are |
| 14 |
secure. Just like |
| 15 |
http://www.openbsd.org/porting.html#Security |
| 16 |
|
| 17 |
And i am asking about a way for me, the user, administrator, to check the |
| 18 |
potential security impacts of the software to install before it is put into |
| 19 |
action. |
| 20 |
|
| 21 |
> > Or even better tools bundled in a "esecurity_check": |
| 22 |
> |
| 23 |
> putting this in an ebuild to be run everytime a pkg is unpacked is kind of |
| 24 |
> dumb (no offense meant) ... |
| 25 |
Thats your point of view. |
| 26 |
|
| 27 |
> we have no 'automated' ways for portage to scan |
| 28 |
> source code looking for potential security issues, nor should there be ... |
| 29 |
> the responsibility lies on the upstream author and the gentoo maintainer, |
| 30 |
> and it should stop there ... |
| 31 |
No, it should not. Site Security doesnt stop at the ebuild maintainer. |
| 32 |
I, as a potential user of "trusted gentoo", would like to have a way to verify |
| 33 |
the work of the developer. I might want to use 3rd party ebuilds, commercial |
| 34 |
ebuilds, special super-hardened ebuild not in normal portage tree, i might |
| 35 |
have requirement complety different from what the developer thought. And also |
| 36 |
it is impossible to bring all those ebuild to the high security standard i |
| 37 |
mention here, so i should have the possibility to verify at emerge time. |
| 38 |
So, instead of "esecurity_check" it should be a portage feature that i can |
| 39 |
switch on. After every unpack or even building the image, just before |
| 40 |
installation, i would like to see what security impacts the package might |
| 41 |
have in its source or how many suid progs it wants to install or whatever. |
| 42 |
And if i say so, the ebuild should not install as soon as the scanners detect |
| 43 |
that the installed software would not conform to my requirements (that i |
| 44 |
would have to define in make.conf). |
| 45 |
|
| 46 |
> perhaps creating tools for developers to use when testing out a new pkg |
| 47 |
> would be feasible ... |
| 48 |
Yes, that would be very nice. |
| 49 |
|
| 50 |
> then again i think if you want a 'secure' box you |
| 51 |
> should follow the excellent work the gentoo-hardened team has put together |
| 52 |
According to whats written on the project side the issue i bring up here is |
| 53 |
not (yet) covered. a secure box can always be compromised by installing |
| 54 |
insecure software. So installing secure software (only) should be made easy |
| 55 |
and verifyable. As portage is responsible for installing software on our |
| 56 |
gentoo machines it should support us in developing and installing secure |
| 57 |
software. |
| 58 |
The feature i bring to discussion here is for sure not the overall solution |
| 59 |
but a little step in the right direction. |
| 60 |
|
| 61 |
It is dumb (no offense meant) to believe the ebuild-maintainer knows about and |
| 62 |
respects the local Site Security Requirements. It is dumb to believe every |
| 63 |
administrator or user is a security expert and can audit each software |
| 64 |
package before installation. |
| 65 |
|
| 66 |
Jan |
| 67 |
> ... -mike |
| 68 |
|
| 69 |
|
| 70 |
-- |
| 71 |
gentoo-dev@g.o mailing list |
Archives