On 6/11/25 12:14, Marc Deslauriers wrote: > It seems I have overlooked this thread, and want to chime in. > > On 2025-06-06 09:40, Attila Szasz wrote: >>> OTOH, is there other significant security impact? As I understood, on >>> Ubuntu a privileged logged in user could use this bug to obtain root. >>> However, is that user perhaps privileged enough to also sudo to root by >>> default? So is this only a bypass of the need to re-enter the user's >>> password for sudo? That sudo from user to root is only a nominal >>> protection mechanism anyway, more against inadvertent mistakes than >>> against malicious attacks. >> >> I didn't make this explicit in the video, but this works when >> running as a non-sudoer user, and also on Ubuntu Server. I think >> Canonical Product Security might have better estimates on this, but >> I'm guessing many of the corporate, gov, academic, HPC cluster, etc >> use cases are impacted practically in such a setting. > > This isn't supposed to work for non-privileged users, and not on servers. We > allow mounting usb drives for admin users sitting at the console by shipping > a > package called "policykit-desktop-privileges" which contains the following > polkit rule: > > [Mounting, checking, etc. of internal drives] > Identity=unix-group:admin;unix-group:sudo > Action=org.freedesktop.udisks2.filesystem-mount-system;org.freedesktop.udisks2.e > ncrypted-unlock-system;org.freedesktop.udisks2.filesystem-fstab; > ResultActive=yes > > Regular unprivileged users should not be in the admin group or the sudo > group, > and as such should not be able to mount usb drives. Servers shouldn't have > that > package installed either. > > Now, that being said, I don't think asking an admin for their password is > enough > justification to allow running arbitrary code. An admin wouldn't expect > inserting a USB drive would allow code execution whether or not they had to > enter their password.
Such code execution is already possible if the drive is vulnerable to BadUSB unless USB keyboards are blocked. That said, I think it would be best for someone (perhaps from Canonical?) who cares about this aspect of security to become a comaintainer of the relevant kernel code. It is clear that there are quite a few people who agree with you, but none of them are currently upstream filesystem maintainers, and they are the ones who Greg K-H asks when making decisions as to what is and is not a vulnerability. -- Sincerely, Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
