[GH-ISSUE #7063] --seccomp= accepts invalid syscall names without warning

gitea-mirror commented

2026-05-05 10:01:09 -06:00

Owner

Originally created by @cobratbq on GitHub (Feb 16, 2026).
Original GitHub issue: https://github.com/netblue30/firejail/issues/7063

Description

I was experimenting with listing seccomp.keep syscalls directly. I discovered that (without noticeable warning) newuname is unknown so did not have an effect.

Your code (current master) contains: uname: 63
Other syscall references list: newuname: 63

I think there's also olduname, but I haven't needed it in whitelisting yet. (Just a heads-up.)

Is there any chance you can make an alias for this, or otherwise make newuname work? This would help w.r.t. whiteliting syscalls, given that applications already start in "highly precariously restricted" environments. 😃

Steps to Reproduce

Add newuname to syscall.keep-list.

Expected behavior

Add newuname to syscall.keep-list and see it show up in seccomp-BPF listing.

Actual behavior

Discover that it isn't in the produced seccomp-BPF listing. Thus newuname call isn't whitelisted. (I didn't know about uname until I checked the code.)

Behavior without a profile

Almost clean profile because I'm screwing around with whitelisting syscalls. So consider it empty, except for a whole swath of syscalls. :-P

Additional context

Nope.

Environment

firejail 0.74
AMD64 arch.

Checklist

I'm sorry for being obnoxious but I don't think the checklist is necessary. Scold me if you think I'm wrong. 😓

Log

Not applicable.

Relates to:

#2931

Originally created by @cobratbq on GitHub (Feb 16, 2026). Original GitHub issue: https://github.com/netblue30/firejail/issues/7063 ### Description I was experimenting with listing `seccomp.keep` syscalls directly. I discovered that (without noticeable warning) `newuname` is unknown so did not have an effect. Your code (current `master`) contains: `uname`: `63` Other syscall references list: `newuname`: `63` I think there's also `olduname`, but I haven't needed it in whitelisting yet. (Just a heads-up.) Is there any chance you can make an alias for this, or otherwise make `newuname` work? This would help w.r.t. whiteliting syscalls, given that applications already start in "highly precariously restricted" environments. 😃 ### Steps to Reproduce Add `newuname` to `syscall.keep`-list. ### Expected behavior Add `newuname` to `syscall.keep`-list and see it show up in seccomp-BPF listing. ### Actual behavior Discover that it isn't in the produced seccomp-BPF listing. Thus `newuname` call isn't whitelisted. (I didn't know about `uname` until I checked the code.) ### Behavior without a profile Almost clean profile because I'm screwing around with whitelisting syscalls. So consider it empty, except for a whole swath of syscalls. :-P ### Additional context Nope. ### Environment - `firejail` 0.74 - AMD64 arch. ### Checklist I'm sorry for being obnoxious but I don't think the checklist is necessary. Scold me if you think I'm wrong. 😓 ### Log Not applicable. Relates to: * #2931

gitea-mirror added the

bug

label 2026-05-05 10:01:09 -06:00

gitea-mirror commented

2026-05-05 10:01:11 -06:00

Author

Owner

@pierretom commented on GitHub (Feb 16, 2026):

I don't think it can be invoked directly by applications, it's used internally by the kernel.
Maybe firejail --seccomp.keep=uname might just be enough in your case ?
Or try with the syscall number on x86_64 firejail '--seccomp.keep=$63'

@pierretom commented on GitHub (Feb 16, 2026): I don't think it can be invoked directly by applications, it's used internally by the kernel. Maybe `firejail --seccomp.keep=uname` might just be enough in your case ? Or try with the syscall number on x86_64 `firejail '--seccomp.keep=$63'`

gitea-mirror commented

2026-05-05 10:01:11 -06:00

Author

Owner

@cobratbq commented on GitHub (Feb 16, 2026):

Wait .. you can do numbers too! Arghh .. okay that's useful.

When restricting Firefox it eventually kills on 'newuname', which indeed seems to be 'uname' (63) but seems listed "everywhere" as newuname. So, it seems to arrive there eventually. Maybe I got confused by interleaved apparmor messaging or smth, but I don't think I did.

@cobratbq commented on GitHub (Feb 16, 2026): Wait .. you can do *numbers too*! Arghh .. okay that's useful. When restricting Firefox it eventually kills on 'newuname', which indeed seems to be 'uname' (63) but seems listed "everywhere" as newuname. So, it seems to arrive there eventually. *Maybe* I got confused by interleaved apparmor messaging or smth, but I don't think I did.

gitea-mirror commented

2026-05-05 10:01:12 -06:00

Author

Owner

@pierretom commented on GitHub (Feb 16, 2026):

Yes use uname with Firefox.

firejail 0.74

You can try to update Firejail too, there are 2 new releases since 0.9.74.

@pierretom commented on GitHub (Feb 16, 2026): Yes use `uname` with Firefox. > * `firejail` 0.74 You can try to update Firejail too, there are 2 new releases since 0.9.74.

gitea-mirror commented

2026-05-05 10:01:13 -06:00

Author

Owner

@kmk3 commented on GitHub (Feb 17, 2026):

Environment

What distribution name/version?

I was experimenting with listing seccomp.keep syscalls directly. I
discovered that (without noticeable warning) newuname is unknown so did not
have an effect.

Your code (current master) contains: uname: 63
Other syscall references list: newuname: 63

firejail 0.74

Why check the code on master if you are using an old version?

This is the tree for 0.9.74:

https://github.com/netblue30/firejail/tree/0.9.74

If the relevant code differs from master, you likely have your answer.

Also, there have been many updates and changes related to syscall mapping after
0.9.78, so it's recommended to use firejail-git if you are having issues with
syscalls:

https://github.com/netblue30/firejail#building

Does the problem happen with firejail-git?

@kmk3 commented on GitHub (Feb 17, 2026): > Environment What distribution name/version? > I was experimenting with listing `seccomp.keep` syscalls directly. I > discovered that (without noticeable warning) `newuname` is unknown so did not > have an effect. > > Your code (current `master`) contains: `uname`: `63` > Other syscall references list: `newuname`: `63` > * `firejail` 0.74 Why check the code on master if you are using an old version? This is the tree for 0.9.74: * https://github.com/netblue30/firejail/tree/0.9.74 If the relevant code differs from master, you likely have your answer. Also, there have been many updates and changes related to syscall mapping after 0.9.78, so it's recommended to use firejail-git if you are having issues with syscalls: * https://github.com/netblue30/firejail#building Does the problem happen with firejail-git?

gitea-mirror commented

2026-05-05 10:01:14 -06:00

Author

Owner

@cobratbq commented on GitHub (Feb 17, 2026):

Maybe there's misunderstanding: I looked for answers in 'master' and what I found was a proper (and correct) explanation/solution. I report what seems like an undesirable discrepancy.

I'm informing you that the syscall that pages and listings list as 'newuname' is in your code-base known as 'uname', thus complicating use. (Also why I enquired about aliasing.) I didn't look in version-branch because 'master' contains the answer and I'm guessing that's more relevant/practical to you.

Granted, now that I know, I (can) use 'uname' and that fixes my problem, but not reporting it would mean the next person is struggling too, possibly.

I appreciate your upgrade recommendation. The earlier recommendations are very useful too.

@cobratbq commented on GitHub (Feb 17, 2026): Maybe there's misunderstanding: I looked for answers in 'master' and what I found was a proper (and correct) explanation/solution. I report what seems like an undesirable discrepancy. I'm informing you that the syscall that pages and listings list as 'newuname' is in your code-base known as 'uname', thus complicating use. (Also why I enquired about aliasing.) I didn't look in version-branch because 'master' contains the answer and I'm guessing that's more relevant/practical to you. Granted, now that I know, I (can) use 'uname' and that fixes my problem, but not reporting it would mean the next person is struggling too, possibly. I appreciate your upgrade recommendation. The earlier recommendations are very useful too.

gitea-mirror commented

2026-05-05 10:01:14 -06:00

Author

Owner

@kmk3 commented on GitHub (Feb 17, 2026):

Maybe there's misunderstanding: I looked for answers in 'master' and what I
found was a proper (and correct) explanation/solution. I report what seems
like an undesirable discrepancy.

I'm informing you that the syscall that pages and listings list as 'newuname'
is in your code-base known as 'uname', thus complicating use. (Also why I
enquired about aliasing.) I didn't look in version-branch because 'master'
contains the answer and I'm guessing that's more relevant/practical to you.

The syscall number/name mapping is pulled straight from the Linux kernel
sources (.tbl files) and there the syscall in question is just called uname.

The older versions are obsolete and are not exposed by the syscall mapping from
the kernel.

It is the same in firejail:

$ firejail --debug-syscalls | grep uname
63      - uname

From uname(2):

   C library/kernel differences
       Over time, increases in the size of the utsname structure have led to
       three successive versions of uname(): sys_olduname() (slot
       __NR_oldolduname), sys_uname() (slot __NR_olduname), and sys_newuname()
       (slot __NR_uname).  The first one used length 9 for all fields; the
       second used 65; the third also uses 65 but adds the domainname field.
       The glibc uname() wrapper function hides these details from
       applications, invoking the most recent version of the system call
       provided by the kernel.

sys_newuname is the function name for the entrypoint, which is internal to
the kernel.

It is arguably an implementation-specific detail not relevant to userspace.

Granted, now that I know, I (can) use 'uname' and that fixes my problem, but
not reporting it would mean the next person is struggling too, possibly.

I appreciate your upgrade recommendation. The earlier recommendations are
very useful too.

Glad they helped.

The following PR should clarify things in the man pages:

#7065

@kmk3 commented on GitHub (Feb 17, 2026): > Maybe there's misunderstanding: I looked for answers in 'master' and what I > found was a proper (and correct) explanation/solution. I report what seems > like an undesirable discrepancy. > > I'm informing you that the syscall that pages and listings list as 'newuname' > is in your code-base known as 'uname', thus complicating use. (Also why I > enquired about aliasing.) I didn't look in version-branch because 'master' > contains the answer and I'm guessing that's more relevant/practical to you. The syscall number/name mapping is pulled straight from the Linux kernel sources (.tbl files) and there the syscall in question is just called `uname`. The older versions are obsolete and are not exposed by the syscall mapping from the kernel. It is the same in firejail: ```console $ firejail --debug-syscalls | grep uname 63 - uname ``` From `uname(2)`: ``` C library/kernel differences Over time, increases in the size of the utsname structure have led to three successive versions of uname(): sys_olduname() (slot __NR_oldolduname), sys_uname() (slot __NR_olduname), and sys_newuname() (slot __NR_uname). The first one used length 9 for all fields; the second used 65; the third also uses 65 but adds the domainname field. The glibc uname() wrapper function hides these details from applications, invoking the most recent version of the system call provided by the kernel. ``` `sys_newuname` is the function name for the entrypoint, which is internal to the kernel. It is arguably an implementation-specific detail not relevant to userspace. > Granted, now that I know, I (can) use 'uname' and that fixes my problem, but > not reporting it would mean the next person is struggling too, possibly. > > I appreciate your upgrade recommendation. The earlier recommendations are > very useful too. Glad they helped. The following PR should clarify things in the man pages: * #7065

gitea-mirror commented

2026-05-05 10:01:15 -06:00

Author

Owner

@kmk3 commented on GitHub (Feb 17, 2026):

I was experimenting with listing seccomp.keep syscalls directly. I
discovered that (without noticeable warning) newuname is unknown so did not
have an effect.

This is a more serious issue though.

It should at least warn on invalid syscall names.

@kmk3 commented on GitHub (Feb 17, 2026): > I was experimenting with listing `seccomp.keep` syscalls directly. I > discovered that (without noticeable warning) `newuname` is unknown so did not > have an effect. This is a more serious issue though. It should at least warn on invalid syscall names.

Rows
Columns

[GH-ISSUE #7063] --seccomp= accepts invalid syscall names without warning #3474

Description

Steps to Reproduce

Expected behavior

Actual behavior

Behavior without a profile

Additional context

Environment

Checklist

Log