Re: [arch-general] Revisiting the SELinux/audit question: Disabling audit on the kernel command line

[Nicolas Iooss]

On Sun, Feb 12, 2017 at 6:43 PM, Tobias Markus  wrote:

> Hi,
>
> As some of you might know, the question of enabling SELinux support in
> the official Arch Linux kernel package has been brought up a number of
> times. The main issue that has been pointed out the previous time was
> that enabling SELinux depends on CONFIG_AUDIT which is considered
> unnecessary or even harmful for most desktop users since it generates a
> flood of kernel log messages.
>

Hi,
Do you have more information about this unwanted flood of messages? From my
personal experience on systems with SELinux and audit, the application
which produces the biggest number of audit events is Chromium, because of
misconfigured seccomp rules that report in audit log every call to
set_robust_list(). This has been reported two years ago on Chromium bug
tracker and the developers seem unwilling to fix it (
https://bugs.chromium.org/p/chromium/issues/detail?id=456535). If there are
similar problems which need to be fixed before thinking of enabling audit
compilation in Arch Linux kernel, where can I find information on them?

Regards,
Nicolas

Re: [arch-general] Experiences with SELinux on Arch

[Nicolas Iooss]

On Fri, Jan 22, 2016 at 11:25 AM, Remi Gacogne <
listes+arch-gene...@valombre.net> wrote:

> Hi Niels,
>
> > since I won't get an answer on the forum except "Read the Wiki" which
> > isn't helpful, I ask here.
> > Is here anybody with real world experiences with SELinux on Arch? The
> > forum states the userland tools as "work in progress" which doesn't say
> > anything about the progress…
> > I'd like to know how easy SELinux is to use on Arch. I am just starting
> > out to (re-)enabling it on my CentOS-servers and there it is actually
> > not that hard after all nowadays because of the great tools available.
> > But how about Arch?
>
> You might want to look at this project:
>
> https://github.com/archlinuxhardened/selinux
> https://github.com/archlinuxhardened/selinux-policy-arch
>
> I know Nicolas is working on making it as easy as possible to use
> SELinux on Arch, and he is doing a great job.
>

I am this Nicolas :) I am currently maintaining the SELinux packages in the
AUR and can answer you with information which is more up to date than the
wiki page (that I don't update often, and thankfully other people are
taking care of it).

First, about the userspace tools and library (libselinux, setools...) and
the programs which need to be recompiled with SELinux support, there are
AUR packages which are working (I am not aware of any bug right now, and am
using them on my systems). I have been working on making the install
process easier for a few years and as there can be some difficulties (like
the build-time circular dependency between util-linux and systemd, which is
not a bug according to https://bugs.archlinux.org/task/39767), I recently
published an install script which builds and installs all SELinux packages
(build_and_install_all.sh in https://github.com/archlinuxhardened/selinux).
You may be interested in using it to get SELinux on Arch.

Then, about the policy, there is currently no publicly-available policy for
Arch Linux, unlike Gentoo, Debian, Fedora and CentOS. For those on the ML
which are not familiar with SELinux but who know firewall configuration,
SELinux is like a firewall for applications and "a SELinux policy" is a set
of rules to filter accesses in a way which is similar to iptables rules
filtering network communications. There is an "upstream" (reference)
policy, from Tresys Technologies (
https://github.com/TresysTechnology/refpolicy), which is used by Debian and
Gentoo (not by Fedora). I am currently working on bringing Arch Linux
support into refpolicy, and this work is still in progress. For example
refpolicy did not have systemd support before its last release (which
happened in December), and now there are still issues with
partially-supported systemd services. I recently updated
selinux-refpolicy-arch AUR packages with some commits from my personal
policy which I'll submit upstream (
https://github.com/archlinuxhardened/selinux-policy-arch/commits/2.20151208),
but it is still not complete for a "base system".

By the way, if anyone wants to take a look at what looks like Arch Linux
with SELinux, for example in a virtual machine, it is possible to create a
Vagrant VM by following the instructions on
https://github.com/archlinuxhardened/selinux/tree/master/_vagrant and then
play in a "vagrant ssh" session.

Finally, for the reasons why SELinux is not integrated to Arch Linux like
Debian (i.e. compiled without being activated by default, contrary to
CentOS and Fedora where SELinux is enabled by default), I believe the three
main points are:

  * support of audit in the kernel (currently there is an annoying bug in
chromium seccomp filters which spams the logs when audit is enabled,
https://code.google.com/p/chromium/issues/detail?id=456535),
  * LSM support in the kernel (e.g. https://bugs.archlinux.org/task/37578 ,
which is more detailed than https://bugs.archlinux.org/task/31448)
  * and package management (libsepol, libselinux and libsemanage would need
to be added to core repository and thus maintained by Arch devs).

I do not see anything today which would lead to the solving of any of these
issues in the short run, so I maintain packages in the AUR and continue
working on the policy. If you feels like helping this work, feel free to
submit pull requests on GitHub (or submit patches upstream).

Nicolas

PS : for the record, I am running a kernel with both SELinux and grsec
(without RBAC) on my systems. These two security systems target different
things and it is possible to use both.

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Nicolas Iooss]

Hello,
2014-03-26 20:18 GMT+01:00 Leonid Isaev lis...@umail.iu.edu:

 On Wed, 26 Mar 2014 19:56:26 +0100
 Thomas Bächler tho...@archlinux.org wrote:

  Hello all,
 
  it won't be too long until 3.14 is out and I want to address a topic
  that has been bugging me for a while. Our kernel includes everything and
  the kitchensink. I have no problem with delivering drivers that can be
  built modular, but there are other things that have an unknown impact on
  everyone.
 
  I want to trim our kernel down to what we actually support.

 Thanks for doing this.

 
  1) Once we agreed to disable one LSM, everyone else said we can enable
  LSM XYZ, too. And so we did. Right now, we enable SELinux, SMACK,
  Tomoyo, AppArmor and Yama, although we don't support the userspace for
  any of those.
 
  I propose to drop all of them.

 I agree regarding SELinux/Apparmor (it's not only userspace tools, but also
 sane application policies that are missing).

I strongly disagree with removing LSM from the packaged kernel. I'm
currently using SELinux with AUR packages [1] (which I help to
maintain) and a custom policy (basically a mix of Tresys' Reference
Policy, Fedora policy and Debian patches [2]) and it works fine. The
only reason behind why nobody hasn't asked yet to make libselinux and
libsepol official packages? is that before this happens, the current
maintainer of these AUR packages wants a working SELinux policy [3].

Here are three arguments to motivate my disagreement.

* First, removing LSM support makes it difficult for users to test
LSM. Before 3.13 kernel, users needed to recompile their kernel (or to
install linux-selinux AUR package) to be able to use SELinux. This is
a hard first step and I know too many people who thinks I don't want
to recompile my kernel as I've already done magical things to make my
graphic card works and I don't want to break my fragile config. Now
people just needs to install packages (from unofficial repos or from
the AUR) as described in the wiki [4] and reboot to start using
SELinux.
* Second, it's possible to compile things which are disabled at
runtime. For example, I don't need to compile the kernel without IPv4
to test what breaks when running a non-IPv4 kernel, I only need to add
a boot parameter and/or a file in /etc/sysctl.d/. It's the same thing
for LSM. Even if they are compiled, they can be enabled/disabled with
such runtime configuration and this config doesn't require much work.
* Third, users who want to combine several unofficial features for
their kernel already have to do weird things. For example, I'm using a
grsec kernel with SELinux. A few months ago, there were linux-grsec
and linux-selinux in the AUR but no package which provided both. Hence
I needed to build a custom package to have both. Now, the next time
linux-grsec's maintainer will sync its config with the official repo,
SELinux will be available in this package (unless I've missed
something) and I'll no longer need to build my custom kernel.

That been said, I agree that having a kernel with less features would
be good. To my mind, here are possible ways :

a) Create a linux-light package with less features than the linux
package, and don't trim linux' configuration.
b) Rename linux as linux-full (as an official package) and trim linux' config.
c) Create a package (linux-src?) which install the kernel sources
and provides an easy way to customize the config before making the
packages (with pkgbuild). Currently linux-grsec AUR package provides
this feature by using the MENUCONFIG environment variable [5].
d) Don't create new packages and trim linux' config (this is your
idea, if I understood correctly).

Any of a) or b) would suits fine for me if you choose to drop LSM in
the lighter config.

Regards,

Nicolas

[1] https://github.com/Siosm/siosm-selinux
[2] https://github.com/fishilico/selinux-refpolicy-patched
[3] https://github.com/Siosm/siosm-selinux/issues/6#issuecomment-32793261
[4] https://wiki.archlinux.org/index.php/SELinux
[5] https://github.com/nning/linux-grsec/blob/master/PKGBUILD#L32

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Nicolas Iooss]

TL;DR: this is a technical answer which can be seen as slightly
off-topic as it focus only on SELinux and not much about kernel config
trimming.

2014-03-27 13:46 GMT+01:00 Thomas Bächler tho...@archlinux.org:
 Am 27.03.2014 09:07, schrieb Nicolas Iooss:
 I agree regarding SELinux/Apparmor (it's not only userspace
 tools, but also
 sane application policies that are missing).

 I strongly disagree with removing LSM from the packaged kernel.
 I'm currently using SELinux with AUR packages [1] (which I help
 to maintain) and a custom policy (basically a mix of Tresys'
 Reference Policy, Fedora policy and Debian patches [2]) and it
 works fine. The only reason behind why nobody hasn't asked yet
 to make libselinux and libsepol official packages? is that
 before this happens, the current maintainer of these AUR packages
 wants a working SELinux policy [3].

 You use AUR packages for all kinds of SELinux stuff, so why not use
 a custom kernel for that?

Because there is a chicken-and-egg issue here. The long term
motivation is to migrate SELinux-compiled duplicated packages (like
sudo, systemd...) from the AUR to official packages (long term
meaning no timeline can be given as there are way too many people
against it). Currently there is a security issue due to package
duplication in the AUR (when a security patch is made for systemd for
example, it takes some time before systemd-selinux is updated). I
won't discuss this more in this thread as it is off topic.

 Here are three arguments to motivate my disagreement.

 * First, removing LSM support makes it difficult for users to
 test LSM. Before 3.13 kernel, users needed to recompile their
 kernel (or to install linux-selinux AUR package) to be able to
 use SELinux.

 So, installing packages from AUR is easy, _except_ when you need
 to install the kernel?

Yes, because there is no easy way to mix two packages. I don't know
any other software which is provided in different packages depending
on their configuration. Most Archlinux packages support via
configure-time switches many things I've never heard about. Why would it
be different for the kernel? (I'm expecting people to ask me this
question and as I don't have any relevant answer yet, I ask it here.)

 This is a hard first step and I know too many people who thinks
 I don't want to recompile my kernel as I've already done magical
 things to make my graphic card works and I don't want to break my
 fragile config. Now people just needs to install packages (from
 unofficial repos or from the AUR) as described in the wiki [4]
 and reboot to start using SELinux.

 So, install a kernel from unofficial repositories or AUR? It's
 just a package.

If you installed modules with DKMS, you also need to recompile these
modules and it may break. I agree that it's just a package and
nothing should break, but that's just theory and in the real world,
things like unsupported DKMS modules break with a custom kernel and
this increases the difficulty a lot. However this increases the
maintenance burden of unsupported things so it's not relevant here.

 * Second, it's possible to compile things which are disabled at
 runtime.

 That they are disabled at runtime does not mean that they have no
 impact at runtime. At best, it's only a performance impact and at
 worst, it even causes problems. The whole idea is to make the
 kernel smaller and to avoid problems caused by things we don't make
 use of.

 Even if they are compiled, they can be enabled/disabled with such
 runtime configuration and this config doesn't require much work.

 Do you even know what that means? If I see this right, every time
 the kernel needs to do some permission check, it needs to ask are
 we using LSM xyz?. In any case, it's more code and thus more room
 for failure.

According to
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/security/security.c?id=v3.13
and
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/security/selinux/hooks.c?id=v3.13#n5977
, the security checks are done using a structure of function pointers
(struct security_operations *security_ops) and the execution path to
check a file permission (at
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/read_write.c#n367
for example) looks exactly the same in both SELinux not compiled and
SELinux compiled but disabled configurations. I may have misunderstood
the code, in such case I'd be glad if you correct me.

 I see where you are coming from and I used to think the same way.
 But after we enabled AppArmor and SELinux in 3.13, the audit
 subsystem was silently enabled - and it is _on_ by default. This
 whole story got me thinking, do we even have any idea what the
 consequences of adding these features are? And I don't think we
 do.

This does sound weird. Could you please give me some references to
this so that I can understand better? I only know that SELinux uses
the audit subsystem to report denials and that the audit subsystem can

Re: [arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Nicolas Iooss]

2014-03-27 16:31 GMT+01:00 Bigby James bigby.ja...@crepcran.com:
 On Thu, Mar 27, 2014 at 09:07:23AM +0100, Nicolas Iooss wrote:

 Here are three arguments to motivate my disagreement.

 * First, removing LSM support makes it difficult for users to test
 LSM. Before 3.13 kernel, users needed to recompile their kernel (or to
 install linux-selinux AUR package) to be able to use SELinux. This is
 a hard first step and I know too many people who thinks I don't want
 to recompile my kernel as I've already done magical things to make my
 graphic card works and I don't want to break my fragile config. Now
 people just needs to install packages (from unofficial repos or from
 the AUR) as described in the wiki [4] and reboot to start using
 SELinux.
 * Second, it's possible to compile things which are disabled at
 runtime. For example, I don't need to compile the kernel without IPv4
 to test what breaks when running a non-IPv4 kernel, I only need to add
 a boot parameter and/or a file in /etc/sysctl.d/. It's the same thing
 for LSM. Even if they are compiled, they can be enabled/disabled with
 such runtime configuration and this config doesn't require much work.
 * Third, users who want to combine several unofficial features for
 their kernel already have to do weird things. For example, I'm using a
 grsec kernel with SELinux. A few months ago, there were linux-grsec
 and linux-selinux in the AUR but no package which provided both. Hence
 I needed to build a custom package to have both. Now, the next time
 linux-grsec's maintainer will sync its config with the official repo,
 SELinux will be available in this package (unless I've missed
 something) and I'll no longer need to build my custom kernel.
 
 As a lowly end-user, I'll have to disagree with you. The bulk of your 
 reasoning
 comes down to *I* use it, so don't take it away from me. But your case is
 hardly representative; I highly doubt that the typical desktop user (that is,
 the typical Arch user) makes use of SELinux or its cohorts; no doubt there are
 people running Arch servers that use it, but again that's not representative 
 of
 the community at large, in which many people just install Arch on their 
 laptops
 and desktops for everyday production and entertainment use.
  
 When I build a custom kernel for my laptop, the LSM stuff and kernel debugging
 options are the first to go, as they have absolutely no benefit for someone 
 who
 uses a computer primarily for reasearch and writing, coding and design work, 
 web
 browsing and music.  They're complements for specific use-cases---server
 administration (most likely when multiple users are involved) and kernel
 hacking, respectively---and are of no use to anyone who doesn't partake in 
 those
 use-cases (how necessary is MAC to someone who interacts with and monitors a
 single machine all day?). Besides, as you've said, you already need to build 
 the
 userspace utilities from source (because not too long ago, the devs voiced 
 their
 opposition to maintaining SELinux officially), so leaving such features in the
 kernel to ease testing is both specious and a mismeasure of how useful or
 vital they might be. Suppose the majority of people who test SELinux decide to
 drop it, as seems to be the case in my (admittedly limited) observations. Of
 what value, then, is the work the devs did to maintain it?
 
Sorry if my message sounded too much as I use it so I want other people
to make my life easier. That was not the intended tone at all. If you
need a bit more background about how I use ArchLinux, let me say I'm
using it on my laptop, where I don't fear to do things that breaks my
system (and if often breaks) because I have easy physical access. When I
needed to set up SELinux on a server (not running Arch) a few months
ago, I decided to first familiarize myself with this software on my
laptop. It took me a long time before having a working system and I'm
trying to reduce that time for other users who might have same ideas as
I (eg. by reporting and helping fixing bugs like
http://lists.gnu.org/archive/html/bug-coreutils/2014-01/msg9.html).

Of course, I'm biased when I speak of SELinux so basically I try to
imagine the state of mind of normal people by replacing SELinux with
Linux containers, which I've never used and see as unneeded weight
(this is a biased unmotivated statement which may be untrue). I don't
know if currently to run LXC or systemd-nspawn you need to recompile
your kernel, but you need at least UTS namespaces, network namespaces...
and I don't know if anyone will consider disabling these features, but I
expect voices to be raised if someone thinks of removing CONFIG_UTS_NS
and CONFIG_NET_NS (or are such decisions expected to happen without
anybody noticing?).

 That been said, I agree that having a kernel with less features would
 be good. To my mind, here are possible ways :

 a) Create a linux-light package with less features than the linux
 package, and don't trim linux