Release 0.9.72 discussion

[kmk3]

Release links:

• Project board: https://github.com/users/netblue30/projects/4
• GitHub Release: https://github.com/netblue30/firejail/releases/tag/0.9.72

Discussion for the previous release:

• Release 0.9.70 discussion #5181

Discussion for the next release:

• Release 0.9.74 discussion #5597

[rusty-snake]

Blockers

• cinelerra-gg: program uses default.profile #5533 (comment)

[kmk3]

So an RC1 was created yesterday:

• https://github.com/netblue30/firejail/releases/tag/0.9.72rc1

@netblue30 When is the intended release date?

Depending on how much time is available, I might try sending a few more fixes.

[netblue30]

I was thinking about the second week of January. We might be able to push it towards the end of the month. Debian goes into soft freeze on Feb 12, we should be done ahead of that. So, dump in everything you have: code, new features, bugs, profiles etc. - business as usual!

After the release we start merging in landlock from @ChrysoliteAzalea - either on a branch or directly on the mainline.

[glitsj16]

Interesting times. Lots of security developments happening in Linux land. Very much looking forward to the landlock feature.

Some things I've put aside for reading during end-of-year holidays:

• tetragon: eBPF-based Security Observability and Runtime Enforcement developed by some kernel developers.
• LSM stackable security modules.

[netblue30]

I'll look into them, thanks!

[netblue30]

I'm cleaning up some things here and there, so continue checking in. Final test and archive build on Saturday.

Problems so far:
--whitelist in /dev directory is broken. I'll probably disable it for the next release.

[kmk3]

@netblue30 on Jan 12:

I'm cleaning up some things here and there, so continue checking in. Final
test and archive build on Saturday.

For reference, there is the URL opening issue from #5566 (see also the
discussion in #5574), though it's not clear how reproducible it is nor when it
was introduced.

Other than that (and the /dev whitelisting issue below), I can't think of any
blockers and I think that everything is in the RELNOTES, so it looks ready for
releasing to me.

Problems so far: --whitelist in /dev directory is broken. I'll probably
disable it for the next release.

Could you clarify what exactly is broken?

It seems to work as intended:

$ firejail --quiet --noprofile --whitelist=/dev/null find /dev
/dev
/dev/null

Is the issue related to new devices not showing up in /dev with private-dev?
(That is, devices that are connected after the sandbox was started)

Anyway, disabling whitelisting in /dev seems like a rather big change to do at
the last minute. How about delaying the release for a week to debug this
instead?

[glitsj16]

@netblue30 All I had in my notes that could be relevant for the upcoming release is in our GitHub system. Either merged or in open PR's (to be reviewed). I did notice the option apparmor-replace is currently not mentioned in the man page. It is only used in firefox-common.profile:

firejail/etc/profile-a-l/firefox-common.profile

Lines 37 to 39 in ee89a26

	apparmor
	# Fixme!
	apparmor-replace

firejail/src/firejail/sandbox.c

Lines 134 to 136 in ee89a26

	if(apparmor_replace){
	fwarning("Replacing profile instead of stacking it. It is a legacy behavior that can result in relaxation of the protection. It is here as a temporary measure to unbreak the software that has been broken by switching to the stacking behavior.\n");
	res = aa_change_onexec(apparmor_profile);

Is this something we should add to the man page nonetheless?

[netblue30]

@kmk3

Thanks for the example, I was trying without --noprofile

$ firejail --quiet --whitelist=/dev/null find /dev
fexecve: No such file or directory
Error: failed to run /run/firejail/lib/fseccomp, exiting...
Error: proc 64143 cannot sync with peer: unexpected EOF
Peer 64144 unexpectedly exited with status 1

Probably we pick up something from one of the profiles. The code is still active, the "fix" was to modify the man page. We'll bring a real fix in the release after this one. Anyway, not too many people are using whitelist /dev.

@glitsj16 - we'll have to do some more work on apparmor in the next release, for now undocumented should be fine.

[netblue30]

Debian stable here, kernel 5.10.0-10-amd64, GLIBC 2.31

[rusty-snake]

execveat() was added to Linux in kernel 3.19. Library support was added to glibc in version 2.34.

[rusty-snake]

If fexecve started to use execveat at the same time we know the reason.

[reinerh]

It works for me as well on Debian stable (kernel 5.10.127, glibc 2.31) with firejail 0.9.70:

$ firejail --quiet --whitelist=/dev/null find /dev
/dev
/dev/null

[netblue30]

Thanks, I'll revert the man page.

[smitsohu]

In order to work around #5010 and #5230, should we have an opt-in/opt-out option or a toggle in firejail.config?

[netblue30]

Maybe toggle in firejail.config?

[netblue30]

This is where I'm at:

Debian stable 64 bits - all fine if I disable restrict namespaces, breaks otherwise. Works fine on @reinerh and several other distros:

$  firejail --ignore=restrict-namespaces --whitelist=/dev/null
Reading profile /etc/firejail/default.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-programs.inc

** Note: you can use --noprofile to disable default.profile **

Parent pid 99861, child pid 99862
Child process initialized in 123.10 ms

Debian old-stable 32 bit - simple /bin/bash sandbox, breaks in restict-namespaces, all fine if I --ignore=restrict-namespaces:

$ firejail --debug
[...]
Build restrict-namespaces filter
sbox run: /run/firejail/lib/fseccomp restrict-namespaces.32 /run/firejail/mnt/seccomp/seccomp.namespaces.32 cgroup,ipc,net,mnt,pid,time,user,uts
Dropping all capabilities
Drop privileges: pid 6, uid 1000, gid 1000, force_nogroups 1
No supplementary groups
fseccomp: seccomp_file.c:26: write_to_file: Assertion `size' failed.
Error: failed to run /run/firejail/lib/fseccomp, exiting...
Error: proc 807 cannot sync with peer: unexpected EOF
Peer 808 unexpectedly exited with status 1

Two or three more days until release.

[netblue30]

OK! The 32 bit platform is fixed now. I'll play around a little bit with whitelist /dev

[glitsj16]

Anything holding up #5563 and #5571 from going in 0.9.72?

[netblue30]

merging now, add on top of them directly.

[netblue30]

Release Monday morning!

[netblue30]

More coming from here: #5591, so probably no release on Monday.

[reinerh]

@netblue30 Can you please make a proper Github release?
The releases page still lists 0.9.72rc1 and 0.9.70.

[kmk3]

@reinerh on Jan 16:

@netblue30 Can you please make a proper Github release?

From the page of the release itself, everything appears to be correct:

• https://github.com/netblue30/firejail/releases/tag/0.9.72

The releases page still
lists 0.9.72rc1 and 0.9.70.

It seems to be an issue with the Releases page (maybe it's cached?).

Note that 0.9.72 is marked as "Latest" on its own page and that there is
nothing else marked as "Latest" on the Releases page.

Edit: 0.9.72 also shows up as the current release on the home page:

• https://github.com/netblue30/firejail

[netblue30]

Probably a bug on GitHub site.

[kmk3]

Reported as a bug:

• https://github.com/orgs/community/discussions/44718

[kmk3]

After editing the release to add the new profiles, it appears on the releases
page:

• https://github.com/netblue30/firejail/releases

[kmk3]

I'm looking to close the 0.9.72 project so that only 0.9.74 appears when trying
to add an issue/PR to a project.

Links:

• 0.9.72
• 0.9.74

@rusty-snake I see that you added a few items to "To Do" on 0.9.72 (and I think
that the rest I copied from items you added on 0.9.70); could you help triage
them? For example:

Items on "To Do" that were fixed on 0.9.72:

• Move it to "Done (on RELNOTES N/A)" on 0.9.72

Items on "To Do" that don't seem to be fixed but that are still relevant:

• Copy it to 0.9.74
• Archive it on 0.9.72
• If applicable, consider asking the author if it was fixed

Items on "To Do" that don't seem to be fixed and that are not relevant anymore:

• Archive it on 0.9.72

(If there's any item that doesn't apply, comment it in here and we'll figure it
out)

This should help ensure that things to be done from that project are not
forgotten. And thus the project can be closed and ignored, which helps avoid
having to keep track of past projects (alongside the current project).

[rusty-snake]

--tab (#4936) shell completions and vim syntax files

Was this originally from you or me?

*Everything else in To Do

All have/are an issue.

[kmk3]

@rusty-snake on Jan 21:

--tab (#4936) shell completions and vim syntax files

Was this originally from you or me?

Now that you mention it, I'm not sure.

I had thought that it was added together with the keepassxc one (which is
archived on 0.9.70 and says that it was added by you), but it's not
archived in the older projects.

Anyway, looks like I added it; archived + copied to 0.9.74.

• Everything else in To Do

All have/are an issue.

To be clear, archiving an item hides it from the project card but keeps it
linked to the project. The status of the issue/PR itself is not affected.

Note: The project archive can be accessed from:

• Menu -> ... -> View archive

By the way, we are the only ones that appear on the Activity feed of 0.9.72 and
the end of it says:

This project was created before project activity started being fully
recorded. There may be gaps in the beginning of this project’s activity.

I'm fairly sure I didn't add any of the remaining (profile-related) issues, so
if you didn't either, feel free to just archive them (or just say so and I'll
archive them). If anyone else remembers adding any of them, feel free to copy
it to 0.9.74.

[rusty-snake]

With "All have/are an issue." I mean: do we need to track them in a project. IMHO we can just archive them.

[kmk3]

@rusty-snake on Jan 21:

With "All have/are an issue." I mean: do we need to track them in a project.
IMHO we can just archive them.

I personally don't mind just archiving these issues; what I meant was mainly
because I don't know why someone might have added any given issue to To Do, so
I'm not sure if anyone would care about just archiving it.

Maybe we could try to define what makes sense to put in the To Do of a release
project. I'll open a separate discussion about it.