- rsbac - rsbac.org

Re: 30 years of RSBAC!
by Jens Kasten 08 Sep '26

08 Sep '26

Am 7. September 2026 09:44:02 UTC schrieb Amon Ott via rsbac <rsbac(a)rsbac.org>: >_______________________________________________ >rsbac mailing list -- rsbac(a)rsbac.org >To unsubscribe send an email to rsbac-leave(a)rsbac.org Hello Amon, congratulations for your 30 years of running RSBAC. This gave a good inspiration to a lot of people and I hope in future too. Jens --- https://kasten-edv.de/download/20E2E753E2621EA07F58F12F90ADFC2DB4AE2408.pub…

1 0

30 years of RSBAC!
by Amon Ott 07 Sep '26

07 Sep '26

Wow, since the first RSBAC code lines for my diploma thesis 30 long years have passed by. This must be the oldest Linux security extension still alive! Alive it is, still maintaining full support for all LTS kernels. Alive it is, still in production use on many servers world wide. Alive it is, still getting feedback from new users. So let us go on and have fun! Amon. -- https://www.rsbac.org GnuPG: E25D2F7B0C561382570DB487DC2A69DA870FE7FF 2018-03-20

1 0

Unmatched NETTEMPs and ignored protocol attribute
by Terence Gomez 11 Aug '26

11 Aug '26

Hello, I have been using network elements in RSBAC and have noticed some strange behaviours. First, specifying a protocol for a NETTEMP when using the NETLINK address family is not taken into account, and the field remains on value ROUTE. For example, setting ANY for the protocol is not registered : $ net_temp list_template 40016 ID: 40016 Name: NETLINK_TEMP Family: NETLINK Socket type: ANY Address: (addresses of family NETLINK not supported) Protocol: ROUTE Netdev: Ports: $ net_temp get_protocol 40016 ROUTE $ net_temp set_protocol 40016 ANY $ net_temp get_protocol 40016 ROUTE This also happens in rsbac_nettemp_def_menu. The same steps are working with INET as address family. Also, some templates I have created and believe should be matched are not matched. In details, I have create a NETTEMP for each address family listed in rsbac_nettemp_def_menu. So, for the INET address family, it looks like : $ net_temp new_template 40002 'INET_TEMP' $ net_temp set_name 40002 'INET_TEMP' $ net_temp set_address_family 40002 INET $ net_temp set_type 40002 ANY $ net_temp set_protocol 40002 ANY $ net_temp set_netdev 40002 '' Then, I created a few NETOBJ RC types to go with the NETTEMPs : # NETOBJ type for NETTEMPs where role 0 will have some rights $ rc_copy_type NETOBJ 0 40 $ rc_set_item TYPE 40 type_netobj_name "NET_autorized" # NETOBJ type for NETTEMPs where role 0 will have no rights $ rc_copy_type NETOBJ 0 41 $ rc_set_item TYPE 41 type_netobj_name "NET_not_autor" # NETOBJ type for default NETTEMPs except "ALL" $ rc_copy_type NETOBJ 0 50 $ rc_set_item TYPE 50 type_netobj_name "NET_defaults" # NETOBJ type for "ALL" default NETTEMP $ rc_copy_type NETOBJ 0 51 $ rc_set_item TYPE 51 type_netobj_name "NET_all" # Setting NETOBJ type for NETTEMPs $ attr_set_net NETTEMP rc_type 40 40002 # INET_TEMP $ attr_set_net NETTEMP rc_type 40 40010 # INET6_TEMP $ attr_set_net NETTEMP rc_type 40 40016 # NETLINK_TEMP $ attr_set_net NETTEMP rc_type 41 40001 # UNIX_TEMP $ attr_set_net NETTEMP rc_type 41 40003 # AX25_TEMP $ attr_set_net NETTEMP rc_type 41 40004 # IPX_TEMP $ attr_set_net NETTEMP rc_type 41 40005 # APPLETALK_TEMP $ attr_set_net NETTEMP rc_type 41 40006 # NETROM_TEMP $ attr_set_net NETTEMP rc_type 41 40007 # BRIDGE_TEMP $ attr_set_net NETTEMP rc_type 41 40008 # ATMPVC_TEMP $ attr_set_net NETTEMP rc_type 41 40009 # X25_TEMP $ attr_set_net NETTEMP rc_type 41 40011 # ROSE_TEMP $ attr_set_net NETTEMP rc_type 41 40012 # DECnet_TEMP $ attr_set_net NETTEMP rc_type 41 40013 # NETBEUI_TEMP $ attr_set_net NETTEMP rc_type 41 40014 # SECURITY_TEMP $ attr_set_net NETTEMP rc_type 41 40015 # KEY_TEMP $ attr_set_net NETTEMP rc_type 41 40017 # PACKET_TEMP $ attr_set_net NETTEMP rc_type 41 40018 # ASH_TEMP $ attr_set_net NETTEMP rc_type 41 40019 # ECONET_TEMP $ attr_set_net NETTEMP rc_type 41 40020 # ATMSVC_TEMP $ attr_set_net NETTEMP rc_type 41 40022 # SNA_TEMP $ attr_set_net NETTEMP rc_type 41 40023 # IRDA_TEMP $ attr_set_net NETTEMP rc_type 41 40024 # PPPOX_TEMP $ attr_set_net NETTEMP rc_type 41 40025 # WANPIPE_TEMP $ attr_set_net NETTEMP rc_type 41 40031 # BLUETOOTH_TEMP $ attr_set_net NETTEMP rc_type 50 100101 # Localnet $ attr_set_net NETTEMP rc_type 50 100102 # Internal_LAN $ attr_set_net NETTEMP rc_type 50 100105 # Auto-IPv4 $ attr_set_net NETTEMP rc_type 51 100110 # ALL # Setting rights on type 40 $ rc_set_item -b ROLE 0 type_comp_netobj 40 0000000000000001000011111110010000000000000010110001100110000000 And now, when booting, some NETOBJs with types 0 and 50 are created and used, whereas they should be matched with NETTEMPs giving them NETOBJ type 40. This one is created as NETOBJ type 0, while it should be 40 if matched with NETLINK_TEMP (but we have seen before that it is stuck with ROUTE as protocol so 51 should be the fallback) : 0000009832|check_comp_rc(): pid 720(dbus-daemon), owner 990, rc_role 0, NETOBJ rc_type 0, request CREATE -> NOT_GRANTED! 0000009834|rsbac_adf_request(): request CREATE, pid 720, ppid 1, prog_name dbus-daemon, prog_file /usr/bin/dbus-daemon, uid 990, audit uid 990, target_type NETOBJ, tid 000000009e5234e2 NETLINK RAW AUDIT, attr sock_type, value RAW, result NOT_GRANTED (Softmode) by RC 0000009836|rsbac_adf_set_attr(): request CREATE, pid 720, uid 990, audit uid 990, target_type NETOBJ, tid 000000009e5234e2 NETLINK RAW AUDIT, new_target_type NONE, new_tid NONE, attr sock_type, value 3, error 0 These ones are created as NETOBJ type 0, while they should be 40 when matched with INET6_TEMP or INET_TEMP 0000009875|check_comp_rc(): pid 717(avahi-daemon), owner 102, rc_role 0, NETOBJ rc_type 0, request CREATE -> NOT_GRANTED! 0000009876|rsbac_adf_request(): request CREATE, pid 717, ppid 1, prog_name avahi-daemon, prog_file /usr/sbin/avahi-daemon, uid 102, target_type NETOBJ, tid 00000000befb6839 INET6 DGRAM proto UDP local [::]:0 remote [::]:0, attr sock_type, value DGRAM, result NOT_GRANTED (Softmode) by RC 0000009877|rsbac_adf_set_attr(): request CREATE, pid 717, uid 102, target_type NETOBJ, tid 00000000befb6839 INET6 DGRAM proto UDP local [::]:0 remote [::]:0, new_target_type NONE, new_tid NONE, attr sock_type, value 2, error 0 and 0000009976|check_comp_rc(): pid 717(avahi-daemon), owner 102, rc_role 0, NETOBJ rc_type 0, request SEND -> NOT_GRANTED! 0000009977|rsbac_adf_request(): request SEND, pid 717, ppid 1, prog_name avahi-daemon, prog_file /usr/sbin/avahi-daemon, uid 102, target_type NETOBJ, tid 00000000762e87fb INET DGRAM proto UDP local 0.0.0.0:5353 remote 224.0.0.251:5353, attr sock_type, value DGRAM, result NOT_GRANTED (Softmode) by RC And this one is created as NETOBJ type 50, while it should be 40 when matched with INET_TEMP 0000009844|check_comp_rc(): pid 717(avahi-daemon), owner 102, rc_role 0, NETOBJ rc_type 50, request CREATE -> NOT_GRANTED! 0000009846|rsbac_adf_request(): request CREATE, pid 717, ppid 1, prog_name avahi-daemon, prog_file /usr/sbin/avahi-daemon, uid 102, target_type NETOBJ, tid 00000000762e87fb INET DGRAM proto UDP local 0.0.0.0:0 remote 0.0.0.0:0, attr sock_type, value DGRAM, result NOT_GRANTED (Softmode) by RC 0000009848|rsbac_adf_set_attr(): request CREATE, pid 717, uid 102, target_type NETOBJ, tid 00000000762e87fb INET DGRAM proto UDP local 0.0.0.0:0 remote 0.0.0.0:0, new_target_type NONE, new_tid NONE, attr sock_type, value 2, error 0 Note that I don't have any NETTEMP that should create a type 0 NETOBJ : $ for NETTEMP_ID in `net_temp list_temp_nr`; do echo "NETOBJ RC type for NETTEMP ${NETTEMP_ID} : " $(attr_get_net RC NETTEMP rc_type $NETTEMP_ID); done NETOBJ RC type for NETTEMP 40001 : 41 NETOBJ RC type for NETTEMP 40002 : 40 NETOBJ RC type for NETTEMP 40003 : 41 NETOBJ RC type for NETTEMP 40004 : 41 NETOBJ RC type for NETTEMP 40005 : 41 NETOBJ RC type for NETTEMP 40006 : 41 NETOBJ RC type for NETTEMP 40007 : 41 NETOBJ RC type for NETTEMP 40008 : 41 NETOBJ RC type for NETTEMP 40009 : 41 NETOBJ RC type for NETTEMP 40010 : 40 NETOBJ RC type for NETTEMP 40011 : 41 NETOBJ RC type for NETTEMP 40012 : 41 NETOBJ RC type for NETTEMP 40013 : 41 NETOBJ RC type for NETTEMP 40014 : 41 NETOBJ RC type for NETTEMP 40015 : 41 NETOBJ RC type for NETTEMP 40016 : 40 NETOBJ RC type for NETTEMP 40017 : 41 NETOBJ RC type for NETTEMP 40018 : 41 NETOBJ RC type for NETTEMP 40019 : 41 NETOBJ RC type for NETTEMP 40020 : 41 NETOBJ RC type for NETTEMP 40022 : 41 NETOBJ RC type for NETTEMP 40023 : 41 NETOBJ RC type for NETTEMP 40024 : 41 NETOBJ RC type for NETTEMP 40025 : 41 NETOBJ RC type for NETTEMP 40031 : 41 NETOBJ RC type for NETTEMP 100101 : 50 NETOBJ RC type for NETTEMP 100102 : 50 NETOBJ RC type for NETTEMP 100105 : 50 NETOBJ RC type for NETTEMP 100110 : 51 Do you have some explanations on why my NETTEMPs are not matched ? Terence Gomez

2 3

Busy weeks at RSBAC
by Amon Ott 07 Jul '26

07 Jul '26

Hi folks, you might have noticed that during the last weeks RSBAC activity has been much higher than usual. Triggered and rechecked by several AI reports as well as some human bug reports and tests, I have been able to squash quite a few bugs, extend RSBAC coverage over some more system calls and improve the infrastructure. Over all, I am pretty pleased with the results: even better stability, more coverage, improved infrastructure through oursourcing of Web Git access to GitWeb and Launchpad with much lower load at rsbac.org, more visibility at search engines etc. Please give RSBAC another try and report your results to the list, all feedback is appreciated. If you like it, tell others! :) Amon. -- https://www.rsbac.org GnuPG: E25D2F7B0C561382570DB487DC2A69DA870FE7FF 2018-03-20

1 0

auth_enable_login causes Oops
by Terence Gomez 07 Jul '26

07 Jul '26

Hello, When I'm using the rsbac_auth_enable_login kernel parameter, the boot produces a kernel Oops. This is the latest kernel 6.18.36 and commit 4cc69f2. Here is an extract of the boot log : [ 2.602556] 0000000041|rsbac_do_init(): reading FD attributes from root dev [ 4.368789] 0000000042|rsbac_init_rc(): Initializing RSBAC: RC subsystem [ 4.383903] 0000000043|rsbac_init_auth(): Initializing RSBAC: AUTH subsystem [ 5.232209] 0000000044|rsbac_do_init(): auth_enable_login is set: setting auth_may_setuid for /bin/login [ 5.232269] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 5.232273] #PF: supervisor instruction fetch in kernel mode [ 5.232276] #PF: error_code(0x0010) - not-present page [ 5.232280] PGD 0 P4D 0 [ 5.232286] Oops: Oops: 0010 [#1] SMP PTI [ 5.232295] CPU: 1 UID: 0 PID: 273 Comm: rsbac_initd Not tainted 6.18.36-rsbac #1 PREEMPT_{RT,(full)} [ 5.232302] Hardware name: HP HP Z240 Tower Workstation/802F, BIOS N51 Ver. 01.92 07/04/2024 [ 5.232306] RIP: 0010:0x0 [ 5.232318] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [ 5.232320] RSP: 0018:ffffcade8165bdd0 EFLAGS: 00010206 [ 5.232325] RAX: 0000000000000000 RBX: ffff8981c267cc30 RCX: 000000000000037d [ 5.232328] RDX: 0000000000000000 RSI: ffff8981c267cc30 RDI: ffff8981c9877778 [ 5.232330] RBP: ffff8981c267c960 R08: 000000006e69676f R09: 0000000000000000 [ 5.232333] R10: ffff8981c267cc30 R11: ffff8981c9877778 R12: ffffcade8165be70 [ 5.232335] R13: 0000000000000000 R14: ffffcade8165bde0 R15: ffff8981c9877778 [ 5.232338] FS: 0000000000000000(0000) GS:ffff8986567b4000(0000) knlGS:0000000000000000 [ 5.232341] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 5.232344] CR2: ffffffffffffffd6 CR3: 0000000148836005 CR4: 00000000003706f0 [ 5.232355] Call Trace: [ 5.232359] <TASK> [ 5.232361] __lookup_slow+0xa3/0x150 [ 5.232412] rsbac_initd+0x1794/0x1b90 [ 5.232444] ? __pfx_rsbac_initd+0x10/0x10 [ 5.232453] kthread+0xfc/0x240 [ 5.232474] ? __pfx_kthread+0x10/0x10 [ 5.232482] ret_from_fork+0x238/0x270 [ 5.232511] ? __pfx_kthread+0x10/0x10 [ 5.232518] ret_from_fork_asm+0x1a/0x30 [ 5.232528] </TASK> [ 5.232529] Modules linked in: ext4 crc16 mbcache jbd2 sd_mod hid_generic usbhid hid xhci_pci xhci_hcd ahci iTCO_wdt libahci intel_pmc_bxt iTCO_vendor_support watchdog libata psmouse e1000e usbcore scsi_mod serio_raw i2c_i801 i2c_smbus usb_common scsi_common video wmi [ 5.232571] CR2: 0000000000000000 [ 5.232577] ---[ end trace 0000000000000000 ]--- [ 5.232579] RIP: 0010:0x0 [ 5.232584] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [ 5.232586] RSP: 0018:ffffcade8165bdd0 EFLAGS: 00010206 [ 5.232589] RAX: 0000000000000000 RBX: ffff8981c267cc30 RCX: 000000000000037d [ 5.232592] RDX: 0000000000000000 RSI: ffff8981c267cc30 RDI: ffff8981c9877778 [ 5.232594] RBP: ffff8981c267c960 R08: 000000006e69676f R09: 0000000000000000 [ 5.232596] R10: ffff8981c267cc30 R11: ffff8981c9877778 R12: ffffcade8165be70 [ 5.232598] R13: 0000000000000000 R14: ffffcade8165bde0 R15: ffff8981c9877778 [ 5.232601] FS: 0000000000000000(0000) GS:ffff8986567b4000(0000) knlGS:0000000000000000 [ 5.232603] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 5.232605] CR2: ffffffffffffffd6 CR3: 0000000148836005 CR4: 00000000003706f0 [ 5.232608] note: rsbac_initd[273] exited with irqs disabled This happens both in softmode and secure mode. Terence Gomez

2 10

RSBAC Git Web access both at GitHub and Launchpad
by Amon Ott 28 Jun '26

28 Jun '26

Hi, Git Web access is now both at GitHub (https://git.rsbac.org/?provider=github) and Launchpad (https://git.rsbac.org/?provider=launchpad) Amon. -- https://www.rsbac.org GnuPG: E25D2F7B0C561382570DB487DC2A69DA870FE7FF 2018-03-20

1 0

Re: Errors on kernel boot
by GOMEZ, Terence 26 Jun '26

26 Jun '26

Hi, This works much better now ! I have been able to correctly boot and log into the system on both machines. However, on some occasions, the login process doesn't start (the logind service times out), so the boot ends with a blinking cursor on a black screen. Of course, there still are the warnings caused by the devtmpfs. Also, how to properly reply to a message on the mailing list ? I tried to use the Reply button but that doesn't help. Terence Gomez Hello again, > > I just pushed some more fixes to 6.18 git. This one should fix the NULL > deref: > commit f78b2c59e54a86b17127523e5a8a22a6e80beaea > aci_data_structures: check for non-null device_p before using it > for FD cache > > The warning traces are harmless, but I will soon look into them again. > Some kernel file systems do not get registered in RSBAC correctly, this > should be located and fixed. > > Your help is appreciated. :) > > Amon. >

3 4

RSBAC Git Web access moved to Github
by Amon Ott 14 Jun '26

14 Jun '26

Due to permanent overload of the rsbac.org server with local Gitweb, I have created shadow repositories at Github. All accesses to https://git.rsbac.org get redirected to the corresponding Github URLs. The Git server at git.rsbac.org remains available and is still the main resource for the latest code. Amon. -- https://www.rsbac.org GnuPG: E25D2F7B0C561382570DB487DC2A69DA870FE7FF 2018-03-20

1 0

Re: Errors on kernel boot
by GOMEZ, Terence 12 Jun '26

12 Jun '26

Hi, Well, now I've got a lot of Oopses with kernel NULL pointer dereferences, which leads to CPU stalls. After a minute, there is a final Oops with a Kernel panic (not appearing in the logs), effectively stopping the boot. Note this is still the config without MAC. Terence Gomez Le ven. 12 juin 2026 à 11:27, Amon Ott via rsbac <rsbac(a)rsbac.org> a écrit : > Hi, > > just pushed a set of fixes to 6.18, the last one adds extra checks to > do_add_mount() and might help. > > Thanks again! > > Amon. > > Am 09.06.26 um 15:35 schrieb GOMEZ, Terence: > > Sure, > > > > I took the same config as before, only disabling CONFIG_RSBAC_MAC in > > the menuconfig. > > I have similar results on the 2 machines : a kernel NULL pointer > > dereference comes up, with a Oops, which then seems to cause a > > deadlock. > > Here are the boot logs. > > > > Le mer. 27 mai 2026 à 16:15, Amon Ott via rsbac <rsbac(a)rsbac.org > > <mailto:rsbac@rsbac.org>> a écrit : > > > > > > Hi Terence, > > > > > > I started looking into this problem, but have not found the reason > yet. > > > Since it seems to crash in the mostly obsolete MAC module code, could > > > you please try without MAC? > > > > > > Amon. > > > > > > Am 22.05.26 um 15:02 schrieb GOMEZ, Terence: > > > > > > > Hi, > > > > > > > > With Jean-Marc Lacroix, we have been trying to enable more options > > than the > > > > default ones for the RSBAC kernel configuration. However, the > > > > configuration we > > > > have come up with does not always boot correctly depending on the > > machine we > > > > install the kernel on. All machines are based on Debian 13, and the > > > > kernels were > > > > launched in softmode, version 6.18.7. > > > > > > > > On the first machine, a Mac Book Pro 2011 (CPU : Intel Core > i5-2415M) > > > > with SysV > > > > init and XFCE, the system comes up properly. > > > > On the second one, a HP Z240 (CPU : Intel Xeon E3-1225) with > > systemd, we > > > > have > > > > first tried the kernel on a Gnome install, where the boot ends up > > with a > > > > "kernel > > > > NULL pointer dereference" and a kernel panic. On the same machine, > > where we > > > > reinstalled a non graphical system, the same kernel configuration > still > > > > produces > > > > the dereference with multiple kernel oops. > > > > On the third one, a Lenovo ThinkStation P520c (CPU : Intel Xeon > > W-2102) with > > > > systemd and no desktop environment, there also is a "kernel NULL > > pointer > > > > dereference" that stops the boot (and is not in the logs), but no > > kernel > > > > panic > > > > is displayed. > > > > > > > > I've appended the config file along with the boot logs. > > > > > > > > Do you have any idea as to why these problems occur ? > > > > > > > > Regards, > > > > > > > > Terence Gomez > > > > > > > > > Amon. > > > > Terence Gomez > > > Amon.

2 1

Errors on kernel boot
by GOMEZ, Terence 12 Jun '26

12 Jun '26

Sure, I took the same config as before, only disabling CONFIG_RSBAC_MAC in the menuconfig. I have similar results on the 2 machines : a kernel NULL pointer dereference comes up, with a Oops, which then seems to cause a deadlock. Here are the boot logs. Le mer. 27 mai 2026 à 16:15, Amon Ott via rsbac <rsbac(a)rsbac.org> a écrit : > Hi Terence, > > I started looking into this problem, but have not found the reason yet. > Since it seems to crash in the mostly obsolete MAC module code, could > you please try without MAC? > > Amon. > > Am 22.05.26 um 15:02 schrieb GOMEZ, Terence: > > > Hi, > > > > With Jean-Marc Lacroix, we have been trying to enable more options than the > > default ones for the RSBAC kernel configuration. However, the > > configuration we > > have come up with does not always boot correctly depending on the machine we > > install the kernel on. All machines are based on Debian 13, and the > > kernels were > > launched in softmode, version 6.18.7. > > > > On the first machine, a Mac Book Pro 2011 (CPU : Intel Core i5-2415M) > > with SysV > > init and XFCE, the system comes up properly. > > On the second one, a HP Z240 (CPU : Intel Xeon E3-1225) with systemd, we > > have > > first tried the kernel on a Gnome install, where the boot ends up with a > > "kernel > > NULL pointer dereference" and a kernel panic. On the same machine, where we > > reinstalled a non graphical system, the same kernel configuration still > > produces > > the dereference with multiple kernel oops. > > On the third one, a Lenovo ThinkStation P520c (CPU : Intel Xeon W-2102) with > > systemd and no desktop environment, there also is a "kernel NULL pointer > > dereference" that stops the boot (and is not in the logs), but no kernel > > panic > > is displayed. > > > > I've appended the config file along with the boot logs. > > > > Do you have any idea as to why these problems occur ? > > > > Regards, > > > > Terence Gomez > > > Amon. Terence Gomez

2 1

2026

2025

2024

2023

rsbac