Bug#812239: linux-grsec-base: grsec RBAC is disabled in kernel config

[Yves-Alexis Perez]

On jeu., 2016-01-21 at 12:20 -0800, Kevin Gallagher wrote:
> This also means that the gradm utility (a package recommended by
> linux-grsec-base, also in the repos as 'gradm2') is unusable, since the
> /dev/grsec device is not exposed:
> 
>     # gradm -P admin
>     Could not open /dev/grsec.
>     open: No such file or directory

By the way, the gradm2 package by itself is unusable since it looks for
/dev/grsec2.

Regards,
-- 
Yves-Alexis



signature.asc
Description: This is a digitally signed message part

Bug#812239: linux-grsec-base: grsec RBAC is disabled in kernel config

[Kevin Gallagher]

Compared to AppArmor, which one trains on specific processes,
Grsecurity's RBAC is the first to provide full system learning that can
automatically generate least-privilege policies covering the entire
system, without manual configuration.

If one is already familiar with writing AppArmor policies, then writing
policies for the grsec RBAC should come naturally. Many average users
are confused by AppArmor logs and don't know how to parse/interpret the
DENIED messages. I personally find that grsec's logging is easier to
read and that I'm able to quickly understand the nature of the violation.

Enabling AppArmor in Debian currently requires installing (sometimes
even building) some software, adding some boot parameters to the Linux
kernel through GRUB, and rebooting. Then you need to fiddle with the
profiles you want, set them to complain/enforce, etc.

If I have RBAC enabled in my grsec kernel, then the /dev/grsec device is
present and I can start using it right away (as long as gradm is installed).

Finally, since I'm already in the habit of quoting from grsecurity.net,
there is much that Grsecurity is able to do through not being reliant on
the Linux Security Modules framework:

"Grsecurity does not use LSM and thus is not constrained by the set
of hooks LSM provides. With this freedom it is able to implement a
number of unconventional features not possible in any LSM. Grsecurity
allows overriding and auto-learning of resource limits on a per-subject
basis, provides per-subject limits on the number of times a service can
crash in a given time interval, can limit access to roles by IP address,
tags policy violation logs with the IP address of the originator of the
violation, provides mandatory control over per-subject PaX flags,
supports policies on individual scripts run directly, and many more
features not available elsewhere."

Bug#812239: linux-grsec-base: grsec RBAC is disabled in kernel config

[Yves-Alexis Perez]

On lun., 2016-02-01 at 07:35 -0800, Kevin Gallagher wrote:
> Compared to AppArmor, which one trains on specific processes,
> Grsecurity's RBAC is the first to provide full system learning that can
> automatically generate least-privilege policies covering the entire
> system, without manual configuration.

That sounds a bit like an advertisement. Could you explain a bit more?

> Enabling AppArmor in Debian currently requires installing (sometimes
> even building) some software, adding some boot parameters to the Linux
> kernel through GRUB, and rebooting. Then you need to fiddle with the
> profiles you want, set them to complain/enforce, etc.
> 
> If I have RBAC enabled in my grsec kernel, then the /dev/grsec device is
> present and I can start using it right away (as long as gradm is installed).

Yeah so you need to enable it in the kernel (or “not disable it, OK), then
install some piece of software. I honestly don't buy the argument (but I don't
think it's relevant anyway). In every case, it's really not that hard to have
the thing enabled.
> 
> Finally, since I'm already in the habit of quoting from grsecurity.net,
> there is much that Grsecurity is able to do through not being reliant on
> the Linux Security Modules framework:

Well, I don't need a quote from grsecurity.net (or AppArmor.net or
SELinux.nsa.gov or whatever), because obviously none will say bad things about
themselves.

Again, I'm not definitely against enabling RBAC, but I'd like something a bit
more convincing…
-- 
Yves-Alexis



signature.asc
Description: This is a digitally signed message part

Bug#812239: linux-grsec-base: grsec RBAC is disabled in kernel config

[Kevin Gallagher]

Package: linux-grsec-base
Version: 5
Severity: normal
Tags: newcomer

Dear Maintainer,

Been playing with the grsec kernel that recently landed in sid (linux-
image-4.3.0-1-grsec-amd64). One issue I discovered is that the RBAC is
disabled in the kernel configuration.

This also means that the gradm utility (a package recommended by
linux-grsec-base, also in the repos as 'gradm2') is unusable, since the
/dev/grsec device is not exposed:

# gradm -P admin
Could not open /dev/grsec.
open: No such file or directory

The grsecurity RBAC (role-based access control)
 is pretty
powerful and has some aspects that make it a superior solution to
AppArmor, SELINUX, etc. in this writer's humble opinion.

I think there is no harm at all in leaving it enabled so that users can
take advantage of it if they wish.

This can be solved by removing the following line (6916) from the kernel
configuration, and rebuilding:

CONFIG_GRKERNSEC_NO_RBAC=y



-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.3.0-1-grsec-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

linux-grsec-base depends on no packages.

Versions of packages linux-grsec-base recommends:
ii  gradm2 3.1~201507191652-1
ii  pax-utils  1.1.4-1
ii  paxctl 0.9-1

linux-grsec-base suggests no packages.

-- Configuration Files:
/etc/sysctl.d/grsec.conf changed [not included]

-- no debconf information

-- 
Twitter: @ageis
XMPP: ag...@jabber.calyxinstitute.org
OTR: 40BDF095 F9968FB2 9E576C9B CFFCAE2E 3740EE04
GPG: 0xB604C32AD5D7C6D8
(415)-767-5566 ext. 13

Bug#812239: linux-grsec-base: grsec RBAC is disabled in kernel config

[Yves-Alexis Perez]

control: tag -1 wishlist

On jeu., 2016-01-21 at 12:20 -0800, Kevin Gallagher wrote:
> Been playing with the grsec kernel that recently landed in sid (linux-
> image-4.3.0-1-grsec-amd64). 

Cool, thanks for testing.

> One issue I discovered is that the RBAC is
> disabled in the kernel configuration.

Indeed.
> 
> This also means that the gradm utility (a package recommended by
> linux-grsec-base, also in the repos as 'gradm2') 

Good point, the recommends should be dropped for now.
> 
> The grsecurity RBAC (role-based access control)
>  is pretty
> powerful and has some aspects that make it a superior solution to
> AppArmor, SELINUX, etc. in this writer's humble opinion.
> 
> I think there is no harm at all in leaving it enabled so that users can
> take advantage of it if they wish.
> 
> This can be solved by removing the following line (6916) from the kernel
> configuration, and rebuilding:

You will need to justify a bit more the two points above before I reconsider
this.
-- 
Yves-Alexis



signature.asc
Description: This is a digitally signed message part

Bug#812239: linux-grsec-base: grsec RBAC is disabled in kernel config

[Kevin Gallagher]

Yves,

I will concede that the various access control systems are "more or
less" equivalent, and I'm just really enthusiastic about grsec's, and
the possibility of making it available to more people in Debian.

As a general matter, I regard the grsecurity RBAC as more comprehensive
and easier to administer. It's highly automated, policies and ACLs are
human-readable, implements least privilege, etc. It can also be used
simultaneously with any other LSM. The following table obviously
concerns way more than just the RBAC, but is still illuminating:
https://grsecurity.net/compare.php

In a separate thread you advocated standardizing around one solution,
which I assume is AppArmor. Have you had any success at getting the
AppArmor LSM to work on this kernel yet? I personally have not. If I had
just those two options, I know which I would choose. I'd point out that
SELinux support is compiled into the Debian kernel as well, though
disabled by default.

At the moment, grsec's RBAC is being actively disincluded, which is
non-default. If one patches the kernel sources with grsecurity and runs
`make menuconfig` and enables it using the Automatic configuration
method, the RBAC will be available. To my mind, the choice of disabling
it warrants more justification than the inverse, since this
configuration is not quite what those who are already familiar with
running grsec would expect.

It would be a different matter if one could toggle the RBAC via sysctl,
but that's not the case; it needs to be built in. If you do that, it's
still going to be off by default (same as SELinux and AppArmor, they all
require bootstrapping), as the gradm tool is required in order to enable
it. I really don't see any issues that could result from simply offering
the capability, and I don't think I'm the only one who uses it.

I don't expect you to be convinced yet, so I may return to this thread
with further arguments and justifications by and by.