Re: [gentoo-user] Re: Choosing between system profiles: hardened and desktop for desktop installation.

[Peter Humphrey]

On Friday 07 Jul 2017 13:25:20 Martin Vaeth wrote:
> Peter Humphrey  wrote:
> > On Friday 07 Jul 2017 07:53:01 Martin Vaeth wrote:
> >> ... my original text was arguing against the claim that the primary
> >> purpose of hardened kernels was to protect against untrusted users
> >> sitting in front of the keyboard.
> > 
> > It wasn't a claim, just an impression
> 
> Sorry that my formulation was unfortunate.
> My intention had been to explain why that impression is wrong IMHO.
> 
> Anyway, this discussion is meanwhile almost pointless since
> hardened-sources are pratically no longer available for "normal"
> users, and so also the hardened profile has become almost pointless.

Yes, but all the same it did start an interesting discussion.

> As a small substitute, I would recommend to follow the recommendations
> of the kernel self projection project and to use the
> 
> default/linux/amd64/17.0/desktop
> 
> profile

Ah. I'm on default/linux/amd64/13.0/desktop/plasma, this being a "stable" 
system. Is there a README or something to explain the differences 13.0 -> 
17.0? Or perhaps I should consider going to ~amd64.

> or - if you are limited to x86 - to combine

> default/linux/x86
> releases/17.0
> targets/desktop
> 
> which enables the current compilers with some default-enabled
> security relevant CFLAGS.
> In addition you can also add -fstack-check=specific
> to CFLAGS and -Wl,-z,now -Wl,-z,relro to LDFLAGS.
> 
> All this is not a complete substitute for TPE and friends but
> better than nothing.

Thanks for the ideas, Martin. I've made that CFLAGS change and added this to 
make.conf:

LDFLAGS="${LDFLAGS} -Wl,-z,now -Wl,-z,relro"

since I didn't have a definition already.

-- 
Regards
Peter

Re: [gentoo-user] Re: Choosing between system profiles: hardened and desktop for desktop installation.

[james]

On 07/07/17 03:53, Martin Vaeth wrote:
> R0b0t1  wrote:
>> On Thu, Jul 6, 2017 at 1:33 AM, Martin Vaeth  wrote:
>>> Peter Humphrey  wrote:
 On Tuesday 04 Jul 2017 10:14:23 Martin Vaeth wrote:
>
> With modern browsers and their complexity, you can expect that any
> website (or the one who has hacked it) can do anything which the
> user of that browser can do if he is sitting on your seat.

 Have you seen any reports of that kind of thing?
>>>
>>> Are you joking? Every CVE of the browser (or of any of its dependencies)
>>> which eventually allows an "execution of arbitrary code" exploit is
>>> such an example.
>>>
 but I'd expect Linux to be less vulnerable.
>>>
>>> This has nothing to do with linux. It is the complexity of the
>>> browser which is the problem.
>>
>> To be fair it is a bit more circuitous on Linux than it is on Windows.
>> [...] you can't directly cause another process to start executing
>> your code directly [...] On Windows there exists CreateRemoteThread.
> 
> If you get your browser to do what you wish (e.g. calling
> CreateRemoteThread on windows) you can usually let it directly execute
> what you wish, anyway.
> 
> So there is hardly a difference from the system.
> 
> I agree that the number of possible exploits for the former was slightly
> decreased if you had a correspondingly configured hardened kernel
> (and provided, of course, that you have not other gapping security holes
> like polkit, systemd, nepomuk/baloo, ... which all suffer from the
> same problem than browsers due to the fact that they provide every user
> access to a much too complex software stack.)

Hmmm. OK, so I avoid systemd and nepomuk (actually all of KDE) but
polkit?  I try and run a minimized DE environment, but on a workstation,
I'm constantly evaluating various codes, so how do I avoid polkit?

# equery d polkit
 * These packages depend on polkit:
app-emulation/libvirt-3.3.0 (policykit ? >=sys-auth/polkit-0.9)
dev-util/sysprof-3.22.2 (gtk ? sys-auth/polkit)
(systemd ? sys-auth/polkit)
gnome-base/gconf-3.2.6-r4 (policykit ? sys-auth/polkit)
gnome-base/gvfs-1.30.4 (policykit ? sys-auth/polkit)
lxde-base/lxsession-0.5.2 (sys-auth/polkit)
net-firewall/ufw-frontends-0.3.2-r5 (policykit ? sys-auth/polkit)
net-print/hplip-3.16.3 (policykit ? sys-auth/polkit)
sys-auth/consolekit-1.1.0-r1 (policykit ? >=sys-auth/polkit-0.110)
sys-block/gparted-0.27.0 (policykit ? sys-auth/polkit)
sys-fs/udisks-1.0.5-r1 (>=sys-auth/polkit-0.110)
sys-fs/udisks-2.6.5 (>=sys-auth/polkit-0.110)
skipper james # equery d udisks
 * These packages depend on udisks:
gnome-base/gvfs-1.30.4 (udisks ? >=sys-fs/udisks-1.97:2)
media-tv/kodi-17.3 (udisks ? sys-fs/udisks:0)
sys-fs/udisks-glue-1.3.5 (>=sys-fs/udisks-1.0.4-r5:0)


Take 'sysprof' for example. Sure I can remove it as nothing is dependent
on it, but installing it does require polkit. So can you explicitly
educate me on polkit, and some strategies to minimize any attack
surfaces it may open?

Reading and keyword searches so I can self-educate on such issues?

So how do we (systematically) minimize or 'partition' such complex
software stacks or follow alternate security strategies?

Then, what is the set of pen_tools we need to run against our networks
to see that it is indeed 'hardened' ? (workstation only atm, but
small self-managed, static IP network in followup).

'Tails' revisited might be a solution, or at least a starting point,
as wikipedia has this to say::

"Tails[1] was first released on 23 June 2009. It is the next iteration
of development on Incognito, a Gentoo-based Linux distribution. "


You know our current hardened leader, blueness, had a very interesting
approach to quick hardened installs [2]. 'Tinhat' was a secure gentoo
that ran completely 'in-ram' but is being scrubbed out of existence.

Or a gentoo centric Whonix [3]? Or a stage-4 [4]?
A common minimized and secure and minimized install for a gentoo
(amd64), would be welcomed by many, rather than a thousand adhoc
threads, imho.

curiously,
James


[1] https://en.wikipedia.org/wiki/Tails_%28operating_system%29

[2]  http://releases.freeharbor.net/

 https://wiki.gentoo.org/wiki/Project:Hardened_musl/Bluedragon

[3] https://www.whonix.org/wiki/HardenedGentooTG

https://www.deepdotweb.com/2014/06/13/simple-whonix-installation-tutorial/


[4]
https://blogs.gentoo.org/gsoc2016-native-clang/2016/07/24/a-new-gentoo-stage4-musl-clang/

Re: [gentoo-user] Re: Choosing between system profiles: hardened and desktop for desktop installation.

[R0b0t1]

On Fri, Jul 7, 2017 at 8:25 AM, Martin Vaeth  wrote:
> Peter Humphrey  wrote:
>> On Friday 07 Jul 2017 07:53:01 Martin Vaeth wrote:
>>
>>> ... my original text was arguing against the claim that the primary
>>> purpose of hardened kernels was to protect against untrusted users
>>> sitting in front of the keyboard.
>>
>> It wasn't a claim, just an impression
>
> Sorry that my formulation was unfortunate.
> My intention had been to explain why that impression is wrong IMHO.
>
> Anyway, this discussion is meanwhile almost pointless since
> hardened-sources are pratically no longer available for "normal"
> users, and so also the hardened profile has become almost pointless.
>

https://wiki.gentoo.org/wiki/Hardened_Gentoo

The hardened profile still sets PaX and a slew of toolchain options.

> As a small substitute, I would recommend to follow the recommendations
> of the kernel self projection project and to use the
>
> default/linux/amd64/17.0/desktop
>
> profile or - if you are limited to x86 - to combine
>
> default/linux/x86
> releases/17.0
> targets/desktop
>
> which enables the current compilers with some default-enabled
> security relevant CFLAGS.
> In addition you can also add -fstack-check=specific
> to CFLAGS and -Wl,-z,now -Wl,-z,relro to LDFLAGS.
>
> All this is not a complete substitute for TPE and friends but
> better than nothing.
>
>

Re: [gentoo-user] Re: Choosing between system profiles: hardened and desktop for desktop installation.

[Peter Humphrey]

On Friday 07 Jul 2017 07:53:01 Martin Vaeth wrote:

> ... my original text was arguing against the claim that the primary
> purpose of hardened kernels was to protect against untrusted users
> sitting in front of the keyboard.

It wasn't a claim, just an impression; and I did say I could easily be 
wrong.

-- 
Regards
Peter

Re: [gentoo-user] Re: Choosing between system profiles: hardened and desktop for desktop installation.

[Jeriko One]

On 07/06/2017 12:28 AM, R0b0t1 wrote:
> To be fair it is a bit more circuitous on Linux than it is on Windows.
> Even if you use (or abuse?) /proc as I outlined in my blurb on
> GRsecurity you can't directly cause another process to start executing
> your code directly, but you can edit its memory, debug it, and mess
> with it in almost every other imaginable way - or you can just find a
> way to get the user to execute some other executable you created on
> disk.
> 
> On Windows there exists CreateRemoteThread.[1] You can force a
> currently loaded process to run whatever code you want.

Not sure what CreateRemoteThread has to do with exploitation. You can't inject 
code in a process with higher privileges than the process you're running as.

> You can solve both of these problems with Role Based Access Controls,
> if you want to bother setting them up. Otherwise process sandboxing
> only applies to resources, not security.

Security is a problem that is never completely solved. Sandboxing and RBAC are 
good mitigations to have in place. If you were able to get code execution 
within a browser that was sandboxed, you could still interact with the kernel 
and attempt to exploit it. This is where the kernel patches that grsec provides 
really help you out. As they make successful exploitation of the kernel more 
difficult. 

Re: [gentoo-user] Re: Choosing between system profiles: hardened and desktop for desktop installation.

[R0b0t1]

On Thu, Jul 6, 2017 at 1:33 AM, Martin Vaeth  wrote:
> Peter Humphrey  wrote:
>> On Tuesday 04 Jul 2017 10:14:23 Martin Vaeth wrote:
>>>
>>> With modern browsers and their complexity, you can expect that any
>>> website (or the one who has hacked it) can do anything which the
>>> user of that browser can do if he is sitting on your seat.
>>
>> Have you seen any reports of that kind of thing?
>
> Are you joking? Every CVE of the browser (or of any of its dependencies)
> which eventually allows an "execution of arbitrary code" exploit is
> such an example.
>
>> but I'd expect Linux to be less vulnerable.
>
> This has nothing to do with linux. It is the complexity of the
> browser which is the problem.
>

To be fair it is a bit more circuitous on Linux than it is on Windows.
Even if you use (or abuse?) /proc as I outlined in my blurb on
GRsecurity you can't directly cause another process to start executing
your code directly, but you can edit its memory, debug it, and mess
with it in almost every other imaginable way - or you can just find a
way to get the user to execute some other executable you created on
disk.

On Windows there exists CreateRemoteThread.[1] You can force a
currently loaded process to run whatever code you want.

You can solve both of these problems with Role Based Access Controls,
if you want to bother setting them up. Otherwise process sandboxing
only applies to resources, not security.

[1] 
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682437(v=vs.85).aspx

Re: [gentoo-user] Re: Choosing between system profiles: hardened and desktop for desktop installation.

[Peter Humphrey]

On Tuesday 04 Jul 2017 10:14:23 Martin Vaeth wrote:
> Peter Humphrey  wrote:
> > hardening is intended
> > more for protection against local threats, like someone else
> > sitting in your seat, than anything coming in over the wires.
> 
> With modern browsers and their complexity, you can expect that any
> website (or the one who has hacked it) can do anything which the
> user of that browser can do if he is sitting on your seat.

Have you seen any reports of that kind of thing? I tend to be sceptical of 
unsubstantiated rumours. No doubt almost anything is possible with the 
World's Worst Operating System, but I'd expect Linux to be less vulnerable.

-- 
Regards
Peter