Mailing List Archive

On Mon, 11 Aug 2014 14:17:12 -0700
Mark Knecht <markknecht@gmail.com> wrote:

> Hi all,
> Just an introduction. First post here but _longtime_ Gentoo user.
> (Early 2003 I think...) I ran Redhat before that starting in 1997.
>
> I'm a basic desktop end-user type. Self-employed, using KDE,
> vlc/makemkv/handbrake, and multiple Virtualbox Win 7 VMs for trading
> in the financial markets. I've converted my wife & 3 generations of my
> family (parents in the 80's and son in his 20's) to Gentoo. None of
> use native Windows anymore. I administer all the systems.

Sounds like an OSS "model family". Congrats! ;-)

> I'm starting to look down the road to a new main machine for me in
> 6 months to 1 year. I'd like to start learning about the whole
> hardened environment - what it can and cannot do, at least easily. If
> I go this direction it's likely to try to be a fully encrypted disk
> subsystem, including initrd. I'm not overly performance driven, but
> that said I want to know where the cycles are going and don't want to
> waste them if possible.

Regarding system performance, my personal experience has been that the
various overheads involved in typical "hardened" Linuxes are
measurable, but not noticeable with most usage patterns. That said,
there's one kind of "performance" which certainly degrades:
Administration performance. You've got to have some time to debug all
these tiny little problems which arise due to badly written software
being incompatible with the system hardening etc.

I'd always recommend encrypting your HDD, even for otherwise
non-hardened systems. Performance losses aren't that bad, and the
advantages are huge. (For example, think about sending in a laptop for
a warranty repair. You don't want to wipe your hdd before, but you also
don't want the vendor to be able to read it.)

On the other hand, I've made some bad experiences with the
initramdisk's required for that. Neither dracut nor genkernel did work
satisfyingly, especially when SELinux entered the equation. I've been
told the situation has improved in the meantime, but I've already
switched to using a custom-written initramdisk. It's rock-solid, easily
understandable and only does those things I want it to do, but those
very well. (Of course, I'm willing to share the sources if someone is
interested.)

> Anyway, thought I'd say hi and look for any pointers about what to
> read for a user such as myself. I'm going through the Gentoo Hardened
> pages and trying to understand what model to use - grsecurity or
> selinux. I'm leaning toward grsecurity but I don't have a good reason
> one way or the other as of yet.

There's much out there on the *net worth a look. Be sure to check out
the Gentoo wiki:
https://wiki.gentoo.org/index.php?title=Special%3APrefixIndex&prefix=Hardened&namespace=0
Oh, and also don't forget reading the help texts of the various
grsecurity kernel options. Most of them are well-documented.

Concerning "grsecurity vs SELinux", you're mixing up something here.
There's SELinux, an "mandatory access control" (MAC) system available
in the main-line kernels. And there's grsecurity/PaX, an extensive set
of kernel patches which is included in hardened-sources. It includes an
"RBAC" subsystem which is similar to SELinux in its purpose, but
grsecurity is much more than that. It has kernel patches for "Kernel
auditing" and "Chroot jail restrictions" to name only a few (as I
said, check out the help texts!) and it includes the PaX suite, which
dictates (among other things) that userland processes can't both write
to a memory region and execute code from there, thereby avoiding a whole
class of common exploits. All of those options are independent of your
using RBAC or SELinux (or no MAC system at all).

For starting out, I'd recommend using PaX and playing around with the
other grsecurity options, but leaving RBAC and SELinux alone, as they
add much more complexity and can be really overwhelming at the
beginning.

Later on, you can still add one of these MAC systems. (I personally do
recommend SELinux, but that's a matter of taste, and as I said, don't
worry about that now.)

> I am interested in trying to do this in a VBox VM just as a
> learning exercise and which I understand it won't be as secure as
> doing it on bare metal I'd be very interested in hearing about others
> experience in this area.

I've never used Virtualbox, but I know hardened-sources kernels work
very well in KVM environments. That said, it's certainly a wise
decision to test substantive system changes beforehand in a virtualized
environment.


Regards,
Luis Ressel

PS: Wow, that mail I've just written somehow reminds me of Duncan.

On 2014-08-12 01:23, Luis Ressel wrote:
> On Mon, 11 Aug 2014 14:17:12 -0700
> Mark Knecht <markknecht@gmail.com> wrote:
>
>> Hi all,
>> Just an introduction. First post here but _longtime_ Gentoo user.
>> (Early 2003 I think...) I ran Redhat before that starting in 1997.
>>
>> I'm a basic desktop end-user type. Self-employed, using KDE,
>> vlc/makemkv/handbrake, and multiple Virtualbox Win 7 VMs for trading
>> in the financial markets. I've converted my wife & 3 generations of
>> my
>> family (parents in the 80's and son in his 20's) to Gentoo. None of
>> use native Windows anymore. I administer all the systems.
>
> Sounds like an OSS "model family". Congrats! ;-)
>
>> I'm starting to look down the road to a new main machine for me
>> in
>> 6 months to 1 year. I'd like to start learning about the whole
>> hardened environment - what it can and cannot do, at least easily.
>> If
>> I go this direction it's likely to try to be a fully encrypted disk
>> subsystem, including initrd. I'm not overly performance driven, but
>> that said I want to know where the cycles are going and don't want
>> to
>> waste them if possible.
>
> Regarding system performance, my personal experience has been that
> the
> various overheads involved in typical "hardened" Linuxes are
> measurable, but not noticeable with most usage patterns. That said,
> there's one kind of "performance" which certainly degrades:
> Administration performance. You've got to have some time to debug all
> these tiny little problems which arise due to badly written software
> being incompatible with the system hardening etc.
>
> I'd always recommend encrypting your HDD, even for otherwise
> non-hardened systems. Performance losses aren't that bad, and the
> advantages are huge. (For example, think about sending in a laptop
> for
> a warranty repair. You don't want to wipe your hdd before, but you
> also
> don't want the vendor to be able to read it.)
>
> On the other hand, I've made some bad experiences with the
> initramdisk's required for that. Neither dracut nor genkernel did
> work
> satisfyingly, especially when SELinux entered the equation. I've been
> told the situation has improved in the meantime, but I've already
> switched to using a custom-written initramdisk. It's rock-solid,
> easily
> understandable and only does those things I want it to do, but those
> very well. (Of course, I'm willing to share the sources if someone is
> interested.)
>
>> Anyway, thought I'd say hi and look for any pointers about what
>> to
>> read for a user such as myself. I'm going through the Gentoo
>> Hardened
>> pages and trying to understand what model to use - grsecurity or
>> selinux. I'm leaning toward grsecurity but I don't have a good
>> reason
>> one way or the other as of yet.
>
> There's much out there on the *net worth a look. Be sure to check out
> the Gentoo wiki:
>
> https://wiki.gentoo.org/index.php?title=Special%3APrefixIndex&prefix=Hardened&namespace=0
> Oh, and also don't forget reading the help texts of the various
> grsecurity kernel options. Most of them are well-documented.
>
> Concerning "grsecurity vs SELinux", you're mixing up something here.
> There's SELinux, an "mandatory access control" (MAC) system available
> in the main-line kernels. And there's grsecurity/PaX, an extensive
> set
> of kernel patches which is included in hardened-sources. It includes
> an
> "RBAC" subsystem which is similar to SELinux in its purpose, but
> grsecurity is much more than that. It has kernel patches for "Kernel
> auditing" and "Chroot jail restrictions" to name only a few (as I
> said, check out the help texts!) and it includes the PaX suite, which
> dictates (among other things) that userland processes can't both
> write
> to a memory region and execute code from there, thereby avoiding a
> whole
> class of common exploits. All of those options are independent of
> your
> using RBAC or SELinux (or no MAC system at all).
>
> For starting out, I'd recommend using PaX and playing around with the
> other grsecurity options, but leaving RBAC and SELinux alone, as they
> add much more complexity and can be really overwhelming at the
> beginning.
>
> Later on, you can still add one of these MAC systems. (I personally
> do
> recommend SELinux, but that's a matter of taste, and as I said, don't
> worry about that now.)
>
>> I am interested in trying to do this in a VBox VM just as a
>> learning exercise and which I understand it won't be as secure as
>> doing it on bare metal I'd be very interested in hearing about
>> others
>> experience in this area.
>
> I've never used Virtualbox, but I know hardened-sources kernels work
> very well in KVM environments. That said, it's certainly a wise
> decision to test substantive system changes beforehand in a
> virtualized
> environment.

I can also confirm that the hardened sources run really well in a xen
virtualized envrionment with pvgrub. I am using grsec with PAX with no
issues at all. I have asked about setting up hardened with a KDE desktop
environment and was told that will take a bit of work.

>
> Regards,
> Luis Ressel
>
> PS: Wow, that mail I've just written somehow reminds me of Duncan.

--
Regards,
Jonathan Aquilina
Founder Eagle Eye T

Encrypted disks are "easy," though some configurations aren't supported
elegantly (using a keyfile, or using an encrypted keyfile). Using genkernel
to create a ramdisk has worked every time for me, dracut has not. (It is
requested Luis Ressel share his ramdisk :)

Hardened is more than usable, though some pre-built software and some
drivers will either require intervention or not work. The software is
usually fixable, stuff that needs to compile against the kernel usually
isn't. Sometimes there's patches.

Hardened with SELinux is kind of usable, but the docs note a desktop
profile isn't supported. I'm not aware of any desktop environments with
working policies - they might exist, but I had to modify policies so much
I'm not sure if I did that or not. I've not used grsecurity's RBAC. It has
a learning mode, but from reading the documentation they seem to both have
the same level of involvement, RBAC possibly more (if you want to check
everything, instead of blindly accepting what it learned).

Regards.



On Tue, Aug 12, 2014 at 12:29 AM, jaquilina <jaquilina@eagleeyet.net> wrote:

> On 2014-08-12 01:23, Luis Ressel wrote:
>
>> On Mon, 11 Aug 2014 14:17:12 -0700
>> Mark Knecht <markknecht@gmail.com> wrote:
>>
>> Hi all,
>>> Just an introduction. First post here but _longtime_ Gentoo user.
>>> (Early 2003 I think...) I ran Redhat before that starting in 1997.
>>>
>>> I'm a basic desktop end-user type. Self-employed, using KDE,
>>> vlc/makemkv/handbrake, and multiple Virtualbox Win 7 VMs for trading
>>> in the financial markets. I've converted my wife & 3 generations of my
>>> family (parents in the 80's and son in his 20's) to Gentoo. None of
>>> use native Windows anymore. I administer all the systems.
>>>
>>
>> Sounds like an OSS "model family". Congrats! ;-)
>>
>> I'm starting to look down the road to a new main machine for me in
>>> 6 months to 1 year. I'd like to start learning about the whole
>>> hardened environment - what it can and cannot do, at least easily. If
>>> I go this direction it's likely to try to be a fully encrypted disk
>>> subsystem, including initrd. I'm not overly performance driven, but
>>> that said I want to know where the cycles are going and don't want to
>>> waste them if possible.
>>>
>>
>> Regarding system performance, my personal experience has been that the
>> various overheads involved in typical "hardened" Linuxes are
>> measurable, but not noticeable with most usage patterns. That said,
>> there's one kind of "performance" which certainly degrades:
>> Administration performance. You've got to have some time to debug all
>> these tiny little problems which arise due to badly written software
>> being incompatible with the system hardening etc.
>>
>> I'd always recommend encrypting your HDD, even for otherwise
>> non-hardened systems. Performance losses aren't that bad, and the
>> advantages are huge. (For example, think about sending in a laptop for
>> a warranty repair. You don't want to wipe your hdd before, but you also
>> don't want the vendor to be able to read it.)
>>
>> On the other hand, I've made some bad experiences with the
>> initramdisk's required for that. Neither dracut nor genkernel did work
>> satisfyingly, especially when SELinux entered the equation. I've been
>> told the situation has improved in the meantime, but I've already
>> switched to using a custom-written initramdisk. It's rock-solid, easily
>> understandable and only does those things I want it to do, but those
>> very well. (Of course, I'm willing to share the sources if someone is
>> interested.)
>>
>> Anyway, thought I'd say hi and look for any pointers about what to
>>> read for a user such as myself. I'm going through the Gentoo Hardened
>>> pages and trying to understand what model to use - grsecurity or
>>> selinux. I'm leaning toward grsecurity but I don't have a good reason
>>> one way or the other as of yet.
>>>
>>
>> There's much out there on the *net worth a look. Be sure to check out
>> the Gentoo wiki:
>>
>> https://wiki.gentoo.org/index.php?title=Special%
>> 3APrefixIndex&prefix=Hardened&namespace=0
>> Oh, and also don't forget reading the help texts of the various
>> grsecurity kernel options. Most of them are well-documented.
>>
>> Concerning "grsecurity vs SELinux", you're mixing up something here.
>> There's SELinux, an "mandatory access control" (MAC) system available
>> in the main-line kernels. And there's grsecurity/PaX, an extensive set
>> of kernel patches which is included in hardened-sources. It includes an
>> "RBAC" subsystem which is similar to SELinux in its purpose, but
>> grsecurity is much more than that. It has kernel patches for "Kernel
>> auditing" and "Chroot jail restrictions" to name only a few (as I
>> said, check out the help texts!) and it includes the PaX suite, which
>> dictates (among other things) that userland processes can't both write
>> to a memory region and execute code from there, thereby avoiding a whole
>> class of common exploits. All of those options are independent of your
>> using RBAC or SELinux (or no MAC system at all).
>>
>> For starting out, I'd recommend using PaX and playing around with the
>> other grsecurity options, but leaving RBAC and SELinux alone, as they
>> add much more complexity and can be really overwhelming at the
>> beginning.
>>
>> Later on, you can still add one of these MAC systems. (I personally do
>> recommend SELinux, but that's a matter of taste, and as I said, don't
>> worry about that now.)
>>
>> I am interested in trying to do this in a VBox VM just as a
>>> learning exercise and which I understand it won't be as secure as
>>> doing it on bare metal I'd be very interested in hearing about others
>>> experience in this area.
>>>
>>
>> I've never used Virtualbox, but I know hardened-sources kernels work
>> very well in KVM environments. That said, it's certainly a wise
>> decision to test substantive system changes beforehand in a virtualized
>> environment.
>>
>
> I can also confirm that the hardened sources run really well in a xen
> virtualized envrionment with pvgrub. I am using grsec with PAX with no
> issues at all. I have asked about setting up hardened with a KDE desktop
> environment and was told that will take a bit of work.
>
>
>
>> Regards,
>> Luis Ressel
>>
>> PS: Wow, that mail I've just written somehow reminds me of Duncan.
>>
>
> --
> Regards,
> Jonathan Aquilina
> Founder Eagle Eye T
>
>

Hi!

I also can confirm workstation with GrSecurity+PaX (without RBAC/SeLinux)
are very ease to setup and works very well nowadays - all you need is
carefully set kernel options related to GrSecurity and PaX and rebuild all
system using hardened gcc.

Problematic software are nvidia-drivers (it works, but require extra
paxmarking for some apps like Xorg and mplayer) and vmware (usually need
extra patches and doesn't work on amd64 for years - virtualbox and
qemu/kvm works ok, so it's not a big deal).

--
WBR, Alex.

Thanks to all that answered. This is going to take some serious study
on my part before it makes sense for me to try anything, even in a VM.

I appreciate all the info.

Cheers,
Mark

On Tue, Aug 12, 2014 at 3:03 AM, Alex Efros <powerman@powerman.name> wrote:
> Hi!
>
> I also can confirm workstation with GrSecurity+PaX (without RBAC/SeLinux)
> are very ease to setup and works very well nowadays - all you need is
> carefully set kernel options related to GrSecurity and PaX and rebuild all
> system using hardened gcc.
>
> Problematic software are nvidia-drivers (it works, but require extra
> paxmarking for some apps like Xorg and mplayer) and vmware (usually need
> extra patches and doesn't work on amd64 for years - virtualbox and
> qemu/kvm works ok, so it's not a big deal).
>
> --
> WBR, Alex.
>