Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Path walk control and cache #9

Open
l0kod opened this issue Jan 18, 2024 · 0 comments
Open

Path walk control and cache #9

l0kod opened this issue Jan 18, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@l0kod
Copy link
Member

l0kod commented Jan 18, 2024 •
edited
Loading

Because of the way path-based LSM hooks work, it is not possible to control some actions such as chdir, which may enable a sandboxed process to infer file names. It would be great to be able to control path walking and then get a complete control on file access with a new LANDLOCK_ACCESS_FS_WALK right.

The LANDLOCK_ACCESS_FS_REFER right (and LANDLOCK_ACCESS_FS_{READ,WRITE}_{FILE,DIR}) would then still allow to open files or directories with O_PATH (which is currently always allowed).

Adding a new LSM hook in filename_lookup() should enable to tie a path to an inode, and then leverage most inode-based LSM hooks. For this to be efficient, we need to implement a small cache per path walk, more generic than an initial approach.

This approach should also significantly improve performance of Landlock's file access control.

See https://lore.kernel.org/all/[email protected]/
@l0kod l0kod added the enhancement New feature or request label Jan 18, 2024
@l0kod l0kod mentioned this issue Jan 18, 2024
Open
This was referenced Jan 30, 2024
Open
Open
@l0kod l0kod added this to Landlock Feb 1, 2024
@l0kod l0kod moved this to Ready in Landlock Feb 1, 2024
l0kod pushed a commit that referenced this issue Sep 9, 2024
@superjamie @gregkh
ethtool: check device is present when getting link settings
842a40c 
[ Upstream commit a699781 ]

A sysfs reader can race with a device reset or removal, attempting to
read device state when the device is not actually present. eg:

     [exception RIP: qed_get_current_link+17]
  #8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede]
  #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3
 #10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4
 #11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300
 #12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c
 #13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b
 #14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3
 #15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1
 #16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f
 #17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb

 crash> struct net_device.state ffff9a9d21336000
    state = 5,

state 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100).
The device is not present, note lack of __LINK_STATE_PRESENT (0b10).

This is the same sort of panic as observed in commit 4224cfd
("net-sysfs: add check for netdevice being present to speed_show").

There are many other callers of __ethtool_get_link_ksettings() which
don't have a device presence check.

Move this check into ethtool to protect all callers.

Fixes: d519e17 ("net: export device speed and duplex via sysfs")
Fixes: 4224cfd ("net-sysfs: add check for netdevice being present to speed_show")
Signed-off-by: Jamie Bainbridge <[email protected]>
Link: https://patch.msgid.link/8bae218864beaa44ed01628140475b9bf641c5b0.1724393671.git.jamie.bainbridge@gmail.com
Signed-off-by: Jakub Kicinski <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
Landlock
Status: Ready
Milestone
No milestone
Development

No branches or pull requests
1 participant
@l0kod