private-etc rework

[netblue30]

Keeping track of private-etc rework here.

From @rusty-snake: TLS CA: ca-certificates,crypto-policies/back-ends,nsswitch.conf,pki/ca-trust,pki/tls,ssl

See the following issue for related links:

• [meta] private-etc rework #6400

[ghost]

At the moment I don't see group and login.defs in any of the defined groups in the reworked private-etc. I'm wondering if it would make sense to add both to the default list to avoid having to add them/keep them in profiles in the future.

firejail/src/include/etc_groups.h

Lines 26 to 41 in b0822c0

	// DEFAULT
	static char *etc_list[ETC_MAX + 1] = { // plus 1 for ending NULL pointer
	"alternatives",
	"fonts",
	"ld.so.cache",
	"ld.so.conf",
	"ld.so.conf.d",
	"ld.so.preload",
	"locale",
	"locale.alias",
	"locale.conf",
	"localtime",
	"nsswitch.conf",
	"passwd",
	NULL
	};

[netblue30]

group and login.defs done!

login.defs actually is required by firejail - we read this file after the filesystem is set. I'll have to move some code around!

[ghost]

Another remark related to (pending) rework of private-etc. I'm not at all against the introduction of these lists, quite the contrary. I do wonder whether hardcoding them is the way forward. If these lists were implemented as includable files, it would be easier for users to add/remove overrides. Just a thought I've been having lately. Maybe it doesn't make sense, maybe it does. Throwing it out here to avoid potential work and all the time and effort it involves having to be redone in the future if some sort of override functionality was desired...

[netblue30]

Will do!

[kmk3]

@glitsj16 on Jan 27:

Another remark related to (pending) rework of private-etc. I'm not at all
against the introduction of these lists, quite the contrary. I do wonder
whether hardcoding them is the way forward. If these lists were implemented
as includable files, it would be easier for users to add/remove overrides.
Just a thought I've been having lately. Maybe it doesn't make sense, maybe it
does. Throwing it out here to avoid potential work and all the time and
effort it involves having to be redone in the future if some sort of override
functionality was desired...

I agree that having support for modifying/overriding the groups would be
beneficial, however I think that maybe this could wait until the groups are
fully working and implemented because:

• There is already a lot of refactoring and breakage happening directly on
  master
• There are multiple ways to do it (and it could potentially be implemented in
  a way that works with other whitelisting-related commands as well)
• The groups themselves are already a big improvement for reducing duplication
  and increasing consistency in profiles

[ghost]

I agree that having support for modifying/overriding the groups would be
beneficial, however I think that maybe this could wait until the groups are
fully working and implemented...

Sure. It was never the intention to influence/prioritize the work being done on private-etc. More of a contextual statement to keep Firejail's override functionality in mind. IMO its flexibility in that regard is one of its biggest strengths.

[netblue30]

Let's do a short cross-distro test on 5 common programs: curl, gimp, inkscape, firefox, and warzone2100. I've tested it on Debian stable and old-stable (10 and 11). If we get these programs running on Arch and Fedora, I think we can deploy it all over. We will modify the existing profiles automatically, so don't touch them yet.

• curl: private-etc TLS-CA
• gimp: private-etc GUI,gcrypt,python*
• inkscape: private-etc GUI,ImageMagick*,python*
• firefox: private-etc GUI,TLS-CA,os-release,mime.types,mailcap
• warzone2100: private-etc GUI,GAMES

[ghost]

In a first round of (basic functionality) tests on Arch Linux the private-etc verdict's pretty awesome: all 5 programs are in good working condition. Sorting issues and CI fall-out aside here's my observations:

• curl (7.87.0-3) --> OK
• firefox (109.0-1) --> OK
• gimp (2.10.32-3) --> OK
• inkscape (1.2.2-4) --> OK (non private-etc hardening can be achieved)
• warzone2100 (4.3.3-1) --> OK (needed to whitelist additional paths to work out-of-the-Arch-box)

I'll open DRAFT PR's for these non private-etc issues: #5630 #5631.

[kmk3]

@netblue30 on Jan 28:

Let's do a short cross-distro test on 5 common programs: curl, gimp,
inkscape, firefox, and warzone2100. I've tested it on Debian stable and
old-stable (10 and 11). If we get these programs running on Arch and Fedora,
I think we can deploy it all over. We will modify the existing profiles
automatically, so don't touch them yet.

• curl: private-etc TLS-CA
• gimp: private-etc GUI,gcrypt,python*
• inkscape: private-etc GUI,ImageMagick*,python*
• firefox: private-etc GUI,TLS-CA,os-release,mime.types,mailcap
• warzone2100: private-etc GUI,GAMES

It is not immediately obvious that all-caps items are considered to be groups.

Also, note that all-caps directories may exist in /etc, such as /etc/X11, which
is part of quite a few private-etc entries:

$ git checkout 0.9.72
HEAD is now at 2551bc71f relnotes update
$ git grep 'private-etc .*X11.*' -- etc/profile-* | wc -l
67
$ git grep 'private-etc .*[A-Z].*' -- etc/profile-* | wc -l
83

And maybe it would make sense to add an X11 group later, which could be
confused with the actual directory.

With that said, recently the following was suggested:

@amano-kenji on Jan 27:

I personally think we shouldn't add individual files to private-etc. There
should be file groups that we give to private-etc.

Like

private-etc @common,@3d,@audio,@dbus,@gui,@gtk,@kde,@networking,@qt

This is also what I thought the private-etc groups would look like, as it uses
the same notation as syscall groups (such as @ipc).

Besides being more consistent with the existing usage, I think that @foo
looks like it refers to something special more than it looks like another item,
(especially when compared to FOO).

So how about using the @groupname notation?

[kmk3]

@glitsj16 on Jan 29:

As this is very early work I consider the syntax to be unstable at the moment
(cfr. your
remark
in the discussion). That being said, I would have expected capitalized names
having precedence and not be mixed in with non-caps items like here now
(GUI,NETWORK,TLS-CA,mailcap,mime.types,os-release). More of a reminder to
tackle these sorting issues in the revamped private-etc. Same goes for the
other changes in this commit.

Another advantage of using @groupname is that @ (0x40) comes before all
letters in ASCII, so groups would by default always be sorted before every path
that starts with letters.

The main potential exceptions would be any paths that start with - (0x2d),
. (0x2e) or numbers (0-9 / 0x30 - 0x39), though I don't know of any such
paths in /etc at least.

Table for reference:

$ pacman -Qo ascii
/opt/plan9/bin/ascii is owned by 9base 6-8
$ ascii
|00 nul|01 soh|02 stx|03 etx|04 eot|05 enq|06 ack|07 bel|
|08 bs |09 ht |0a nl |0b vt |0c np |0d cr |0e so |0f si |
|10 dle|11 dc1|12 dc2|13 dc3|14 dc4|15 nak|16 syn|17 etb|
|18 can|19 em |1a sub|1b esc|1c fs |1d gs |1e rs |1f us |
|20 sp |21  ! |22  " |23  # |24  $ |25  % |26  & |27  ' |
|28  ( |29  ) |2a  * |2b  + |2c  , |2d  - |2e  . |2f  / |
|30  0 |31  1 |32  2 |33  3 |34  4 |35  5 |36  6 |37  7 |
|38  8 |39  9 |3a  : |3b  ; |3c  < |3d  = |3e  > |3f  ? |
|40  @ |41  A |42  B |43  C |44  D |45  E |46  F |47  G |
|48  H |49  I |4a  J |4b  K |4c  L |4d  M |4e  N |4f  O |
|50  P |51  Q |52  R |53  S |54  T |55  U |56  V |57  W |
|58  X |59  Y |5a  Z |5b  [ |5c  \ |5d  ] |5e  ^ |5f  _ |
|60  ` |61  a |62  b |63  c |64  d |65  e |66  f |67  g |
|68  h |69  i |6a  j |6b  k |6c  l |6d  m |6e  n |6f  o |
|70  p |71  q |72  r |73  s |74  t |75  u |76  v |77  w |
|78  x |79  y |7a  z |7b  { |7c  | |7d  } |7e  ~ |7f del|

[netblue30]

All set, thanks for the idea!

[ghost]

Afterthoughts on big profile changes.

In general this makes detecting typos and other oddities much easier now.
For typos, see #5641.

Regarding oddities. I spotted two profiles (still) having firejail in private-etc. These self-referencing issues should be fixed (see #2877):

• ghostwriter
• peek (has it in private-bin too)

[ghost]

Notes on private-etc: groups modified:

• Trolltech.conf --> @X11
• selinux --> @default

A quick scan of the profiles currently shows there's only one private-etc comment still using the old format:

firejail/etc/profile-a-l/ephemeral.profile

Lines 57 to 58 in 2e4e9d1

	# private-etc below works fine on most distributions. There are some problems on CentOS.
	#private-etc alternatives,asound.conf,ca-certificates,crypto-policies,dconf,fonts,group,gtk-2.0,gtk-3.0,hostname,hosts,ld.so.cache,localtime,login.defs,machine-id,mailcap,mime.types,nsswitch.conf,os-release,pango,passwd,pki,pulse,resolv.conf,selinux,ssl,X11,xdg

• we seem to have a bug with profiles using net none:

$ firejail --net=none --private-etc=java*
Error mount: fs_etc.c:142 fs_resolvconf: No such file or directory
Error: proc 79088 cannot sync with peer: unexpected EOF

I'll do some bisecting later today.

[ghost]

Notes on private-etc: java directory fixes:

Until we bring in private-etc globbing support, these changes won't work...
See commit comment and related discussion.

[netblue30]

globbing is already there, I put it in when I did the first change to private-etc.

[ghost]

Yeah I'm in the middle of experimenting with it. Very nice work all round. Thanks!

[kmk3]

@glitsj16 @netblue30

After commit 5d0822c ("private-etc: big profile changes", 2023-02-05), there
are multiple profiles that seem to have an unrelated group in private-etc.

It might not be possible to fix this with certainty without reverting this and
later commits.

I'll explain in a separate issue; please avoid making changes to profiles on
master in the mean time.

[ghost]

@kmk3 Interesting. I'll hold off any changes. In fact my 'board' is pretty much cleared besides looking into the aforementioned net none bug.

[kmk3]

Opened #5645 for the revert; it briefly explains the main issues. I might
later open a discussion dedicated to that, but for now feel free to discuss
them in the PR.

Update: Besides the profiles, please avoid making changes to any files that
5d0822c touched (including the "etc-cleanup" tool), as it would have to be
reverted as well for the original revert to work (because of conflicts).

[rusty-snake]

FTR the profile template need tobr updated as well.

[netblue30]

OK, so I have a cleanup tool installed in /usr/lib/firejail directory:

 /usr/lib/firejail/etc-cleanup -h
usage: cleanup-etc [options] file.profile [file.profile]
Group and clean private-etc entries in one or more profile files.
Options:
   --debug - print debug messages
   -h, -?, --help - this help screen
   --replace - replace profile file
$ 

It looks something like this:

$ /usr/lib/firejail/etc-cleanup p3.profile 

********************
file: p3.profile

old: private-etc ssl,ca-certificates,os-release,xdg,drirc,mime.types,mailcap

new: private-etc @tls-ca,@x11,mailcap,mime.types,os-release

It will group the files and order them alphabetically. With --replace it will overwrite the original file if necessary.

[SkewedZeppelin]

re: machine-id:

I'm seeing issues in some programs like keepassxc for example on Fedora 37 with these changes

dbus[23]: D-Bus library appears to be incorrectly set up: see the manual page for dbus-uuidgen to correct this issue. (Failed to open "/var/lib/dbus/machine-id": No such file or directory; Failed to open "/etc/machine-id": No such file or directory)
  D-Bus not built with -rdynamic so unable to print a backtrace

strace only shows the first file as well:

$ strace /usr/bin/keepassxc 2>&1 | grep machine
openat(AT_FDCWD, "/var/lib/dbus/machine-id", O_RDONLY) = 8
openat(AT_FDCWD, "/var/lib/dbus/machine-id", O_RDONLY) = 10
openat(AT_FDCWD, "/var/lib/dbus/machine-id", O_RDONLY|O_CLOEXEC) = 21

$ file /var/lib/dbus/machine-id
/var/lib/dbus/machine-id: symbolic link to /etc/machine-id

I also have seen some weird behavior with d1124df which appears to cause some programs (like repo) to fail eg. when attempting to write to /etc because read-only which didn't occur previously. and doesn't fail when it can't write when out of firejail

[ghost]

Do these programs work when adding the new private-etc @sound in a foo.local override (private-etc machine-id in oldspeak)? Maybe it's another variation of #5650.

[SkewedZeppelin]

yes they work when private-etc machine-id is there
I don't think it is related to #5650, was able to reproduce (the dbus issue) without net none declared

[rusty-snake]

Known, the qt dbus library crashes if it fails to read machine-id (the actual ID doesn't matter).

[netblue30]

Problem solved, thanks @SkewedZeppelin - 633016f