private-etc templates

[SkewedZeppelin]

I've been testing many of the profiles under Fedora 27 and quite a few are broken due to private-etc. See [0], [1], [2]. I think we should try and create some standardized templates for private-etc, test that they work across many distros, and then update all of the profiles. Optionally even create aliases (private-etc @[template]) to make it easier to maintain.

To start:

• Internet: ca-certificates,crypto-policies,nsswitch.conf,pki,resolv.conf,ssl
• Sound: alsa,asound.conf,machine-id,openal,pulse
• Window Frameworks: fonts,gtk-2.0,gtk-3.0,pango,xdg

We also need to figure out when the following are necessary

• group,host*,localtime,passwd,selinux,drirc

[0] - 68ccf1e
[1] - 4efa2d8
[2] - #1724 (comment)

[d2s]

It might make sense to have an ability to run the test suite on multiple distributions more easily.

Would it make sense to use whole virtual machines, or do Docker containers (or similar) provide enough of help for testing different platforms more frequently? Knowing that different distributions package applications in different ways (and most likely with different compiler settings), there are various ways same applications can work on different systems.

[Fred-Barclay]

Great idea @SpotComms!
I'm curious if we always need localtime to be included. There are probably some instances like Tor where we might not want to expose the local time inside the sandbox.
machine-id is another one that we might not want to include for every profile... but if I understand your post correctly it would only be included for programs that need audio.

[SkewedZeppelin]

@Fred-Barclay Yes, we definitely need to figure out when localtime and those others are needed. And machine-id does seem to be necessary for PulseAudio now.

[Fred-Barclay]

I don't remember - can we use the machine-id filter (not the private-etc argument, but the one that spoofs a new /etc/machine-id) and still have working audio?

[Fred-Barclay]

@SpotComms How about we set up a checklist of distros and programs to test various private-etc filters and programmes so we can do this without duplicating each other's work? Something like

• Ubuntu

  • firefox

  • vlc

• Arch

  • firefox

  • vlc

• Fedora

  • firefox

  • vlc

• Debian Stable

  • firefox

  • vlc

• Debian Sid

  • firefox

  • vlc

EDIT: actually it might be better to set up a Project to keep track - what do you think?

[SkewedZeppelin]

@Fred-Barclay the checklist is simpler. I'll test the machine-id option right now on Fedora.

Edit:

So I tested machine-id with Lollypop on Fedora
neither = no audio
private-etc machine-id = working audio
machine-id = no audio
machine-id and private-etc machine-id = no audio

on Arch however, it appears neither are necessary for audio to work

[Fred-Barclay]

Hmmm... oh well. I wonder why machine-id and private-etc machine-id break audio?

Somewhat unrelated question - are you running firejail 0.9.53 on Fedora? I haven't figured out how to build it without errors (see #1583, which we need to get fixed).

[SkewedZeppelin]

@Fred-Barclay 0.9.52, I too haven't figured out how to get either of the RPM build scripts to work.

[Fred-Barclay]

I wonder how @netblue30 builds the rpms? We could probably figure out how to fix the scripts from that.

[d2s]

Is there a visible error message on a terminal if an application (like Firefox, etc.) does not have access to the required files? Could that be used as a part of automated tests in the future, if the issue is happening more frequently?

[topimiettinen]

Pulseaudio uses machine id for some purposes, so audio may break in all programs using Pulseaudio with random machine-id.

[smitsohu]

For KDE apps, the following seems to be a consensus: fonts,kde4rc,kde5rc,ld.so.cache,machine-id,xdg. I've tested some apps on Arch, Fedora, Debian, KDE Neon (Ubuntu), and updated their profiles in 8aec769

Without machine-id I found the apps fail to start on Fedora Gnome (with D-Bus error).

I omitted passwd for now, everything seems to run ok without.... kdenlive already had passwd before, and I don't feel comfortable dropping it because I'm not overly familiar with the program

[smitsohu]

It is only a detail, but do we actually need pulse in private-etc? Not that it hurts much to include it, but from my understanding firejail ensures that there is a local client.conf, so the global one in /etc should be always ignored.

[smitsohu]

We also need to figure out when the following are necessary
group,host*,localtime,passwd,selinux

I don't know close to anything about selinux, but it is maybe worth noting that we blacklist /etc/selinux in disable-common.inc

[SkewedZeppelin]

@smitsohu I agree we might be able to remove pulse and in general blacklist selinux (although some programs do seem to fopen it, they still seem to work without). If possible I'd like to remove passwd and related files.

[smitsohu]

Regarding localtime: The current Apparmor base abstraction contains the following

  # The __canary_death_handler function writes a time-stamped log
  # message to /dev/log for logging by syslogd. So, /dev/log, timezones,
  # and localisations of date should be available EVERYWHERE, so
  # StackGuard, FormatGuard, etc., alerts can be properly logged.
  /dev/log                       w,
  /dev/random                    r,
  /dev/urandom                   r,
  /etc/locale/**                 r,
  /etc/locale.alias              r,
  /etc/localtime                 r,
  /etc/writable/localtime        r,
  /usr/share/locale-bundle/**    r,
  /usr/share/locale-langpack/**  r,
  /usr/share/locale/**           r,
  /usr/share/**/locale/**        r,
  /usr/share/zoneinfo/           r,
  /usr/share/zoneinfo/**         r,
  /usr/share/X11/locale/**       r,
  /{,var/}run/systemd/journal/dev-log w,
  # systemd native journal API (see sd_journal_print(4))
  /{,var/}run/systemd/journal/socket w,
  # Nested containers and anything using systemd-cat need this. 'r' shouldn't
  # be required but applications fail without it. journald doesn't leak
  # anything when reading so this is ok.
  /{,var/}run/systemd/journal/stdout rw,

  /usr/lib{,32,64}/locale/**             mr,
  /usr/lib{,32,64}/gconv/*.so            mr,
  /usr/lib{,32,64}/gconv/gconv-modules*  mr,
  /usr/lib/@{multiarch}/gconv/*.so           mr,
  /usr/lib/@{multiarch}/gconv/gconv-modules* mr,

Do we consider this relevant for us?

On another note, we probably will want to make /etc/dconf available to most Gnome apps, as settings can be locked there and will then override the local configuration (KDE keeps its global overrides in kde4rc, kde5rc and xdg).