| 1 |
On Tue, Jul 4, 2017 at 4:12 AM, Peter Humphrey <peter@××××××××××××.uk> wrote: |
| 2 |
> On Tuesday 04 Jul 2017 05:20:41 Ian Bloss wrote: |
| 3 |
>> You should use the hardened profile with the harden sources. On terms with |
| 4 |
>> security you could compile a hardened kernel but you sacrifice ease of |
| 5 |
>> use by having to manage pax and if you choose an RBAC system like SElinux |
| 6 |
>> or grsecuritys adds more burden. |
| 7 |
>> |
| 8 |
>> Security isn't a product, so I would recommend sticking with regular |
| 9 |
>> profile with stable packages, and be mindful of what you have opened up to |
| 10 |
>> the internet. I would also recommend just reading up on linux security in |
| 11 |
>> general to understand what you're trying to make yourself more secure to. |
| 12 |
> |
| 13 |
> I second that last point. I looked into hardened Gentoo some years ago and |
| 14 |
> came to the conclusion that it wasn't worth all the extra trouble. My |
| 15 |
> impression (though I could easily be wrong) is that hardening is intended |
| 16 |
> more for protection against local threats, like someone else sitting in your |
| 17 |
> seat, than anything coming in over the wires. |
| 18 |
> |
| 19 |
|
| 20 |
The majority of the hardening is applied to kernel structures that |
| 21 |
most people never interact with and don't know exist. The changes are |
| 22 |
supposed to make it harder to glean information about the inner |
| 23 |
workings of the kernel, as many exploits require rather intimate |
| 24 |
knowledge about what the kernel is doing and when. |
| 25 |
|
| 26 |
There were some more noticeable parts that turned certain parts of |
| 27 |
/sys and /proc off, but you could either whitelist or blacklist a |
| 28 |
certain group. This is actually one of the more novel additions, as |
| 29 |
both places provide a lot of information that is useful for attacking |
| 30 |
a system.[1] Related changes also made things like chroot jails work |
| 31 |
as intended and prevent data from leaking into or out of them. |
| 32 |
|
| 33 |
The additions that do things like prevent USB devices not plugged in |
| 34 |
since boot as working are mainly intended for server environments, |
| 35 |
where you don't want technicians or janitors to be able to attack your |
| 36 |
servers by exploiting faulty USB drivers. This also helps prevent |
| 37 |
individuals with always-on workstations to some extent, but if that is |
| 38 |
what you are afraid of you should carry your trusted computer on your |
| 39 |
person at all times. |
| 40 |
|
| 41 |
[1] Depending on what is exposed in /proc any process running as a |
| 42 |
user can make arbitrary changes to any other process running as that |
| 43 |
user, so by compromising e.g. a web browser you have effectively |
| 44 |
become that user. It's worth noting similar functionality is also |
| 45 |
available via ptrace (the syscall that implements most debugging |
| 46 |
functions). |
| 47 |
|
| 48 |
On Tue, Jul 4, 2017 at 12:44 PM, Toralf Förster <toralf@g.o> wrote: |
| 49 |
> On 07/04/2017 07:12 AM, Ста Деюс wrote: |
| 50 |
>> So, I would like to use the |
| 51 |
>> hardened profile and then add the desktop packages, namely openbox w/o |
| 52 |
> |
| 53 |
> I do run a hardened profile at my desktop (KDE) since about 3 years - |
| 54 |
> almost w/o any trouble. |
| 55 |
> |
| 56 |
> Recently I switched just from hardened kernel to vanilla kernel - b/c |
| 57 |
> the hardened PAX kernel (GRsecurity) isn't any longer freely available |
| 58 |
> and the vanilla is nowadays at 4.12. |
| 59 |
> |
| 60 |
> Works fine so far. |
| 61 |
> |
| 62 |
|
| 63 |
Apparently I misread the initial announcement. It didn't originally |
| 64 |
look like GRsecurity had withdrawn all nonpaid support, but I guess |
| 65 |
they have. I will be going back to the vanilla sources if that is the |
| 66 |
case. |
| 67 |
|
| 68 |
Do you know how the concept of a hardened toolchain is going to be |
| 69 |
preserved going forward? |
Archives