Bug 283425 - [nullfs] nosuid bypass
Summary: [nullfs] nosuid bypass
Status: In Progress
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: Unspecified
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-12-19 21:32 UTC by Sulev-Madis Silber
Modified: 2024-12-27 06:26 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sulev-Madis Silber 2024-12-19 21:32:32 UTC
mounting nullfs from the source directory that resides on filesystem that has nosuid option configured allows suid execution again

explicitly mounting nullfs with nosuid disables it

however, mount, in both cases shows that nosuid is set, when in reality it isn't
Comment 1 Sulev-Madis Silber 2024-12-19 21:38:52 UTC
23:35,root@green:~# lh ping
-r-sr-xr-x  1 root  wheel    61K Oct 30 14:35 ping
23:35,root@green:~# mount_nullfs /root/ /mnt/
23:35,root@green:~# mount | fgrep ' /mnt '
/root on /mnt (nullfs, local, noatime, nosuid, nfsv4acls)
23:35,root@green:~# su -fm nobody -c '/root/ping -o example.com'
ping: socket ssend: Operation not permitted
23:35,root@green:~# su -fm nobody -c '/mnt/ping -o example.com'
PING6(56=40+8+8 bytes) 2001:7d0:8437:1300:21e:bff:fea2:e000 --> 2606:2800:21f:cb07:6
820:80da:af6b:8b2c
16 bytes from 2606:2800:21f:cb07:6820:80da:af6b:8b2c, icmp_seq=0 hlim=55 time=92.991
 ms

--- example.com ping6 statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 92.991/92.991/92.991/0.000 ms
23:35,root@green:~#
Comment 2 Konstantin Belousov freebsd_committer freebsd_triage 2024-12-19 22:18:04 UTC
This is purely a display issue, the nosuid flag is reported when it is not set
and should be not shown then.

https://reviews.freebsd.org/D48150
Comment 3 Sulev-Madis Silber 2024-12-19 23:09:26 UTC
what about others, noexec and nosymfollow do it too?

additionally, if src is updated, no options change in null. maybe it can't be done but it's confusing. eg fs becomes ro, is ro but doesn't show it's ro
Comment 4 Sulev-Madis Silber 2024-12-19 23:17:41 UTC
this also confuses 100.chksetuid and 110.neggrpperm which now wrongly exclude fses from check list
Comment 5 Konstantin Belousov freebsd_committer freebsd_triage 2024-12-19 23:32:00 UTC
(In reply to Sulev-Madis Silber from comment #3)
Do you mean that the whole idea of copying the lower fs mnt_flags is not useful?
I think that I would agree with such statement.
Comment 6 Sulev-Madis Silber 2024-12-20 00:03:33 UTC
(In reply to Konstantin Belousov from comment #5)
yes. it would confuse hell out of tools and users if some options appear to be configured and they are not. esp one that actually (try) to impose restrictions and are supposed to increase security, even if only a little bit

i honestly believed that lower fs limits are respected. unsure, from manpage, such things aren't very clear too

but what if it instead of lying of flags, it would actually use them? if you mount null from ro fs, it won't become rw suddenly (i actually tried it). perhaps this could be configured from somewhere

i mean, nullfs is popular in jails and unsure which is better way for it to operate

but it should behave consistently

i wonder how many systems suddenly start reporting suid binaries from either periodic or from some other ids tools since mount output just lied. might actually have something there too. or just the fact that you think you have those options configured. exec and suid was not only allowed but nothing checked fses too since it's cheap and easy to check if fs even supports it

i realize that this is maybe not that good practice but confusion is also bad and everyone is human. luckily i outright tested what i configured. i expected it to be nosuid, tried anyway, looked at mount, didn't get why it's still on
Comment 7 commit-hook freebsd_committer freebsd_triage 2024-12-20 16:11:46 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=709989bab5d060763bb8fd8e75d33f8bd1d454ad

commit 709989bab5d060763bb8fd8e75d33f8bd1d454ad
Author:     Konstantin Belousov <kib@FreeBSD.org>
AuthorDate: 2024-12-19 22:14:20 +0000
Commit:     Konstantin Belousov <kib@FreeBSD.org>
CommitDate: 2024-12-20 15:58:29 +0000

    nullfs: stop lying about mount flags in statfs(2)

    Flags should not propagate from the lower fs.  Behavior for the upper fs
    is determined by flags from its mount point structure.  When lower fs
    acts according to its mount configuration, it is reported up as VOP
    errors.

    PR:     283425
    Reviewed by:    markj
    Sponsored by:   The FreeBSD Foundation
    MFC after:      1 week
    Differential revision:  https://reviews.freebsd.org/D48150

 sys/fs/nullfs/null_vfsops.c | 5 -----
 1 file changed, 5 deletions(-)
Comment 8 commit-hook freebsd_committer freebsd_triage 2024-12-27 06:26:46 UTC
A commit in branch stable/14 references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=57d12ea5c9b07a6407e3518aeb2383f29be727d2

commit 57d12ea5c9b07a6407e3518aeb2383f29be727d2
Author:     Konstantin Belousov <kib@FreeBSD.org>
AuthorDate: 2024-12-19 22:14:20 +0000
Commit:     Konstantin Belousov <kib@FreeBSD.org>
CommitDate: 2024-12-27 06:24:55 +0000

    nullfs: stop lying about mount flags in statfs(2)

    PR:     283425

    (cherry picked from commit 709989bab5d060763bb8fd8e75d33f8bd1d454ad)

 sys/fs/nullfs/null_vfsops.c | 5 -----
 1 file changed, 5 deletions(-)