1 |
Fernando Rodriguez <frodriguez.developer@×××××××.com> wrote: |
2 |
|
3 |
> On Sunday, September 06, 2015 1:15:17 PM walt wrote: |
4 |
> > https://wiki.gentoo.org/wiki/Hardened_Gentoo |
5 |
> > |
6 |
> > That wiki page is very seductive. It makes me want to drop |
7 |
> > everything and select a hardened profile and re-emerge everything |
8 |
> > from scratch. |
9 |
> > |
10 |
> > But I have a feeling I'd soon be in big trouble if I did. Is this |
11 |
> > something that only gentoo devs should be messing with, or is this |
12 |
> > a project that a typical gentoo end-user might hope to accomplish |
13 |
> > without frequent suicidal thoughts? |
14 |
> |
15 |
> There's different opinions on it, but mine is that while it adds some |
16 |
> security it's so little that it's not worth it in most cases. It |
17 |
> provides more security on a binary distro because everyone has the |
18 |
> same binaries and an attacker don't need to guess where a specific |
19 |
> piece of code may get loaded but by running a source distro your |
20 |
> address space is already pretty unique. The only case where it |
21 |
> provides some security is when an attacker is trying to guess an |
22 |
> address for an exploit, making the wrong guess will likely crash the |
23 |
> process and it will be reloaded on a new address. Do you have |
24 |
> valuable enough data for an attacker to go through that hassle in |
25 |
> order to get it? If you do then you should use a hardened profile, |
26 |
> but physical security and disk encryption is more important because |
27 |
> if it's worth that much it'll be easier to just rob you. |
28 |
|
29 |
I'm not a security expert, so I'm maybe wrong here, But I think there |
30 |
are more security functions on gentoo-hardened than just address space |
31 |
randomization. There are also things like stack smash protection and |
32 |
some other restrictions that make it harder to exploit security holes. |
33 |
|
34 |
> Be aware that there's no hardened desktop profile so that alone will |
35 |
> make it somewhat harder if plan to use it on a desktop. |
36 |
|
37 |
I never used a desktop profile. I just added the USE flags that I need. |
38 |
|
39 |
> Another reason is if you want to use something like SELinux (which |
40 |
> doesn't require a hardened profile) that gives you very fine grained |
41 |
> control about access control but it's also very restrictive. I think |
42 |
> it's only worth it for large networks with many users and different |
43 |
> levels of access to sensitive data. |
44 |
|
45 |
Yes, SELinux can be very painfull and I also don't use it. |
46 |
|
47 |
> I needed some of SELinux features but settled for using AppArmor in |
48 |
> an unusual way to accomplish them because SELinux is too much |
49 |
> trouble. All AppArmor really does is provide process isolation or |
50 |
> sandboxing. If an attacker gains access through an exploint he will |
51 |
> only be able to access the files that the exploited service has |
52 |
> access to. I use it with a catch all profile that prevents execution |
53 |
> from all world writeable and home directories, and access to ssh/pgp |
54 |
> keys, keyrings, etc. This works nice for servers and desktops and is |
55 |
> not too restrictive. And if I need to execute code from my home dir |
56 |
> for development I can launch an unrestricted shell via sudo. I can |
57 |
> leave my laptop unlocked with the wallet open (I use the kwallet pam |
58 |
> module) and it will be really hard for you to get anything like ssh |
59 |
> keys or passwords (I also have patches for kwallet so it requires a |
60 |
> password to show saved passwords), but the programs that need them |
61 |
> have access to them. |
62 |
|
63 |
I will give AppArmor a try when I have more spare time. |
64 |
|
65 |
-- |
66 |
Regards |
67 |
wabe |