1 |
I second this!! |
2 |
I would love to see gentoo be more "proactive by default"... |
3 |
sanboxing services whenever possible (like its done with dhcpd and bind) |
4 |
priv-separation wherever doable, inclusively porting software from |
5 |
openbsd, like their new dhcp server and clients and ntp server :) |
6 |
|
7 |
I say this but don't "show code" simply because i'm not that |
8 |
experienced to implement "safer" code, |
9 |
nor to chroot a lot of software, nor am I capable of evaluate if such |
10 |
service is chrootable :) |
11 |
|
12 |
for instance, would there be any advantage in chrooting mysql? what |
13 |
about tomcat? |
14 |
is java code free from the dreadfull buffer overflow + shellcode? |
15 |
|
16 |
So.. I support very dearly this idea.. |
17 |
|
18 |
greetings to all, |
19 |
and thanks to all gentoo developers for gentoo :D |
20 |
|
21 |
On Wed, 22 Sep 2004 19:49:42 -0400, Ned Ludd <solar@g.o> wrote: |
22 |
> On Wed, 2004-09-22 at 11:54, John Richard Moser wrote: |
23 |
> > -----BEGIN PGP SIGNED MESSAGE----- |
24 |
> > Hash: SHA1 |
25 |
> > |
26 |
> > It may be prudent to use extra protection on certain ebuilds in standard |
27 |
> > Gentoo profiles where the changes would be significant in the case of a |
28 |
> > security fault in the program. Such programs as daemons and chmod()+s |
29 |
> > programs would be major targets for this sort of thing. |
30 |
> > |
31 |
> > The most immediately apparent route to take would be to have ebuilds |
32 |
> > such as openssh, apache, and su stack smash protected. This would |
33 |
> > prevent common buffer overflow attacks from being used to compromise |
34 |
> > security; such attacks would only cause the program attacked to abort, |
35 |
> > which could still be used as a Denial of Service attack, but would not |
36 |
> > allow successful intrusion. |
37 |
> > |
38 |
> > Gentoo ships gcc with stack smash protection built in. This is |
39 |
> > activated by -fstack-protector or -fstack-protector-all. It would be |
40 |
> > feasible to add one of these flags to an ebuild based on a FEATURES or |
41 |
> > USE setting. |
42 |
> > |
43 |
> > I believe it would be a good idea to have such a FEATURES or USE flag on |
44 |
> > by default in all profiles where SSP is supported. In this manner, the |
45 |
> > major targets of security attacks would automatically be protected; |
46 |
> > while still allowing the user to disable the protection if the user |
47 |
> > desires. Users wanting more protection can simply add -fstack-protector |
48 |
> > to CFLAGS, or use Hardened Gentoo. |
49 |
> > |
50 |
> > Any comments? Would this be more suitable as a USE or a FEATURES setting? |
51 |
> |
52 |
> |
53 |
> This would indeed significantly reduce impact of many existing security |
54 |
> problems that could potentially introduce and execute arbitrary code. |
55 |
> |
56 |
> Yes this makes complete and total sense in the terms of what your saying |
57 |
> here. Vs using hardened which is not ideal for everybody or all |
58 |
> occasions(due to the other things it enables by default) to limit the |
59 |
> use of -fstack-protector to/for setuid/setgid and services only. |
60 |
> |
61 |
> I fully support this idea for atleast all base system packages that fall |
62 |
> under the conditions you have defined, and assuming to many trolls don't |
63 |
> come out of the woodwork I would be willing start on it if you can make |
64 |
> a detailed list. |
65 |
> |
66 |
> As far as a disable feature how about FEATURES="noautossp" ? |
67 |
> |
68 |
> > |
69 |
> > - -- |
70 |
> > All content of all messages exchanged herein are left in the |
71 |
> > Public Domain, unless otherwise explicitly stated. |
72 |
> > |
73 |
> > -----BEGIN PGP SIGNATURE----- |
74 |
> > Version: GnuPG v1.2.6 (GNU/Linux) |
75 |
> > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org |
76 |
> > |
77 |
> > iD8DBQFBUaBOhDd4aOud5P8RAv/sAKCGx+cy5D3U35jDvGEFV5fcInF2fwCfbvGM |
78 |
> > QvF8iaV8fuNFVQcintwy+2o= |
79 |
> > =4Gdc |
80 |
> > -----END PGP SIGNATURE----- |
81 |
> > |
82 |
> > -- |
83 |
> > gentoo-dev@g.o mailing list |
84 |
> -- |
85 |
> Ned Ludd <solar@g.o> |
86 |
> Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer |
87 |
> |
88 |
> |
89 |
> |
90 |
> |
91 |
|
92 |
|
93 |
|
94 |
-- |
95 |
Miguel Sousa Filipe |
96 |
|
97 |
-- |
98 |
gentoo-security@g.o mailing list |