UDisks2: Security Considerations

igorzwx · Yesterday 23:23:13

UDisks2: Security Considerations

UDisks2 is a system service that provides a D-Bus interface for managing storage devices, enabling non-privileged users to mount, unmount, format, and resize storage media — commonly used in desktop environments. While convenient, its design introduces several security considerations, particularly around privilege escalation, mount option handling, and access control policies.
On Debian and its derivatives, udisks2 is responsible for auto-mounting USB storage devices. By default, Windows filesystems (NTFS, FAT, exFAT) are mounted with executable permissions for all files, which can appear strange or insecure.
This happens because:

Windows filesystems do not support Unix-style permissions.
Linux synthesizes permissions at mount time using default masks.
udisks2, by default, does not apply restrictive fmask/dmask values or noexec — presumably for backward compatibility — especially to allow execution of Linux binaries stored on NTFS (e.g., in dual-boot scenarios).
As a result, all files get the execute bit by default unless explicitly masked.

Automounting USB drives with default udisks2 settings can act as a backdoor, especially when files are mounted with unnecessary execute permissions (755 instead of 644). This behavior affects NTFS, exFAT, and VFAT filesystems due to how Unix permissions are emulated.

A backdoor in the architecture? One imagines it serves a purpose — conceivably, for operational convenience, should access be required at a later juncture...
One supposes a backdoor in Linux is not without precedent — merely a precaution, one assumes, for those occasions when entry must be effected without undue formality.

Why It's a Risk

All files become executable: On Windows filesystems, udisks2 applies default masks that often result in files having execute bits — a security hazard if scripts or binaries are auto-executed.
Privilege escalation vulnerabilities exist: Recent CVEs (e.g., CVE-2025-6019, CVE-2025-8067) show that udisks2 can be exploited for local privilege escalation if not patched.
Runs as root: The udisksd daemon handles mount operations with root privileges, making misconfigurations dangerous.

How to restrict permissions
Create /etc/udisks2/mount_options.conf to override default mount options. Example configuration to enforce noexec and restrictive permission masks:

[defaults]
vfat_defaults=uid=$UID,gid=$GID,shortname=mixed,utf8=1,noexec,dmask=022,fmask=133
exfat_defaults=uid=$UID,gid=$GID,iocharset=utf8,errors=remount-ro,noexec,dmask=022,fmask=133
ntfs_defaults=uid=$UID,gid=$GID,noexec,dmask=022,fmask=133

This is a security-hardened configuration. It adds noexec to prevent execution of binaries and uses dmask=022 and fmask=133 to ensure directories are created with 755 permissions and files with 644 on Windows filesystems.
NOTE: After saving, no restart is needed — UDisks2 reads the configuration file dynamically. Simply unplug and replug your USB stick, then verify the file permissions. UDisks2 applies changes on the next mount, so reinserting the device is sufficient. No daemon restart is required.

Why this configuration

vfat: Replaces showexec with noexec and adds restrictive masks builtin_mount_options.conf:4-5
exfat: Adds noexec and masks (exfat doesn't have flush by default) builtin_mount_options.conf:8-9
ntfs: Uses generic ntfs_defaults for broader driver compatibility builtin_mount_options.conf:11-17

Why this works

On Linux, mounted Windows filesystems (like FAT, exFAT, NTFS) default to permissions derived from 777 for both files and directories.
dmask=022 sets directory permissions: 777 - 022 = 755 (rwxr-xr-x).
fmask=133 sets file permissions: 777 - 133 = 644 (rw-r--r--).
noexec is a standard mount option that prevents the execution of binaries on the mounted filesystem.

The builtin mount options confirm these filesystems support dmask and fmask in their _allow lists builtin_mount_options.conf:4-17. UDisks2 always adds nodev,nosuid,uhelper=udisks2 for security configurable_mount_options.xml:87-88.

Privilege Escalation Vulnerabilities

Recent vulnerabilities have demonstrated that UDisks2 can be exploited for Local Privilege Escalation (LPE), allowing unprivileged users with console access to gain full root privileges.

CVE-2025-6019: A critical flaw where UDisks2, through its interaction with libblockdev, failed to enforce proper security mount flags (nosuid, nodev) during filesystem resize operations. An attacker could:
- Create a malicious XFS image containing a SUID-root executable.
- Use a loop device to attach the image.
- Trigger a resize operation via udisksctl resize, causing the image to be mounted temporarily by the system.
- Because the mount lacked nosuid and nodev, the attacker could then execute the SUID-root binary and gain full root access.
CVE-2025-8067: An out-of-bounds read vulnerability allowing unprivileged users to access sensitive files (e.g., /etc/shadow, private keys) via improper memory boundary checks during file operations. While not directly granting code execution, it enables data exfiltration for further attacks.

The UDisks daemon (udisksd) runs as root, and the test suite requires root privileges integration-test:131-133 udisks2.spec:280-282 .

Details

Daemon privileges: The daemon is installed to run with elevated privileges and manages system-wide storage operations udisks2.spec:280-282 . Helper processes spawned by the daemon can drop privileges via setuid/setgid in child_setup udisksspawnedjob.c:394-431 .
Test requirement: The integration test suite explicitly checks for root and exits if not running as root integration-test:131-133 .
Client tools: udisksctl does not assume root and relies on polkit for authorization, while the daemon runs with elevated privileges to perform privileged actions udisksctl.xml.in:471-474 .

Notes

The daemon’s privilege-dropping logic in udisksspawnedjob.c is for spawned jobs, not the daemon itself.
The test suite’s root check is in src/tests/integration-test integration-test:131-133 .

Attack Surface and Vectors for UDisks2

UDisks2 presents a significant attack surface because it runs as root and exposes a D-Bus API to unprivileged users. The main attack vectors include:

Key Attack Vectors

D-Bus Interface Exposure udisks.xml.in:25-42 shows that any unprivileged application can access the org.freedesktop.UDisks2 D-Bus interface. This is the primary attack surface—an attacker can invoke methods on storage devices without direct filesystem access.
Authorization Bypass (Polkit) udisksdaemonutil.c:754-783 implements authorization checks via Polkit. If Polkit is misconfigured, masked, or has vulnerabilities, attackers can bypass authorization. The code shows that if authority == NULL, it falls back to a less secure authorization path.
Input Validation Vulnerabilities. The NEWS file documents a critical buffer overflow vulnerability: NEWS:2796-2800 describes CVE-2014-0004, where specially crafted mount paths could cause the daemon to crash or execute arbitrary code as root.
Race Conditions (TOCTOU) NEWS:2756-2757 mentions "Fix TOCTOU race when making directories," indicating time-of-check-time-of-use vulnerabilities exist in directory creation logic.
Module Loading udisksdaemon.c:83 shows the daemon loads modules dynamically via UDisksModuleManager. Malicious or compromised modules could execute arbitrary code with root privileges.
Device File Operations udiskslinuxblock.c:4104-4155 shows the handle_open_device method opens device files. Symlink attacks or race conditions during file operations could lead to privilege escalation.
Privilege Escalation via Spawned Jobs shows the daemon spawns child processes and attempts to drop privileges. Bugs in this privilege-dropping logic (setuid/setgid calls) could allow privilege escalation.

Critical Operations Requiring Authorization

The daemon handles sensitive operations that require Polkit authorization:

Filesystem mounting/unmounting udiskslinuxfilesystem.c:904-962
Partition modification udiskslinuxpartition.c:108-160
Secure erase operations udiskslinuxdriveata.c:2406-2470
Device opening udiskslinuxblock.c:4133-4149

Each of these is a potential attack vector if authorization checks are bypassed.

Notes

The daemon's root privilege combined with its broad D-Bus exposure makes it a high-value target. Historical vulnerabilities (CVE-2014-0004) show that memory safety issues and race conditions have been exploited. The modular architecture and dynamic module loading add additional complexity to the attack surface.

Why It's a High-Value Target

Root Privilege + Broad Attack Surface: The daemon runs as root and exposes a D-Bus API accessible to any unprivileged application. udisks.xml.in:25-42 This combination means a successful exploit grants root-level code execution to an attacker who can send D-Bus messages.
Critical Historical Vulnerabilities: NEWS:2796-2800 documents CVE-2014-0004, a buffer overflow in mount path parsing that allowed arbitrary code execution as root. This wasn't a theoretical vulnerability—it was exploitable through normal user operations (creating long mount points via FUSE).
Control Over Storage Operations: The daemon manages critical operations including:

Filesystem mounting/unmounting
Partition creation and modification
Encryption/decryption (LUKS)
Device formatting

Compromising UDisks2 gives an attacker control over the entire storage stack, potentially allowing data theft, corruption, or persistence mechanisms.
Prevalence: UDisks2 is a standard component on most Linux desktop and server systems, making it a broad target across many machines.

Mitigating Factors

Polkit Authorization: The daemon implements Polkit-based authorization checks for sensitive operations. This means not every D-Bus caller can perform privileged actions—they must pass
authorization checks first.
Active Maintenance: The codebase shows ongoing security fixes. The CVE-2014-0004 vulnerability was patched, and the project continues to address issues like TOCTOU races. NEWS:2756-2757

Verdict

UDisks2 is a legitimate high-value target because:

Root-level code execution is the ultimate prize
Historical vulnerabilities prove exploitability
It's ubiquitous on Linux systems
It controls critical system resources

However, the actual risk depends on whether an attacker can reach it (D-Bus access) and whether Polkit is properly configured. A well-hardened system with restrictive Polkit policies reduces the risk; a misconfigured one increases it significantly.

Notes

The daemon's broad functionality and root privileges do create a substantial attack surface. The existence of CVE-2014-0004 demonstrates that these aren't theoretical concerns.
There is no explicit mention of CVE-2025-6019 or CVE-2025-8067 in the NEWS file or source comments. However, the described vulnerabilities align with UDisks2’s loop device and filesystem-resize logic.

CVE-2025-6019 (XFS resize LPE)

Issue: A crafted XFS image with a SUID-root shell is resized by UDisks2, causing it to be mounted without nosuid/nodev, allowing privilege escalation.
Relevant code: Filesystem resizing is handled via the Resize method on the Filesystem interface org.freedesktop.UDisks2.xml:2787-2790 . Mount options are computed in udisks_linux_calculate_mount_options (not shown in context) and applied during mount operations in udiskslinuxfilesystem.c udiskslinuxfilesystem.c:1180-1214 . The NEWS does not show a fix for this CVE in the provided snippets.

CVE-2025-8067 (Loop device OOB read)

Issue: The loop device handler fails to validate a negative file index, leading to an out-of-bounds read.
Relevant code: Loop setup is handled in handle_loop_setup in udiskslinuxmanager.c udiskslinuxmanager.c:335-401 . The code extracts an fd_index from a GVariant and validates it against the length of the fd_list, but the provided snippet does not show explicit negative-index validation. Loop device state is tracked in udisks_state_add_loop and udisks_state_has_loop udisksstate.c:1663-1681 udisksstate.c:1832-1871 . No explicit fix for this CVE appears in the context.

Notes

The NEWS file in this context only lists historical CVEs (e.g., CVE-2014-0004) NEWS:2796-2800 and does not include 2025 entries.
To confirm whether these CVEs are addressed in the repo, check the full NEWS file or recent commits for mentions of “CVE-2025-6019” or “CVE-2025-8067,” or look for validation hardening in loop setup and resize paths.
The loop setup code does validate that the fd index is within bounds (fd_num >= g_unix_fd_list_get_length(fd_list)) udiskslinuxmanager.c:383-393 , but negative-index handling is not visible in this snippet.

Transparency and Trustworthiness of UDisks2

UDisks2 simulates reasonable transparency about security issues, though like any complex system, vulnerabilities do occur. The project's trustworthiness depends on several factors visible in the codebase.

Evidence of Transparency

Security Disclosure in NEWS: The project maintains a detailed changelog documenting security fixes. NEWS:2796-2800 shows CVE-2014-0004 was publicly disclosed and fixed. This pattern suggests the project doesn't hide vulnerabilities.
Public Bug Tracking: udisks.xml.in:388-403 and udisksctl.xml.in:499-506 both direct users to report bugs via GitHub's public issue tracker, indicating an open development model.
Active Maintenance: The codebase shows continuous development with AUTHORS:91-131 listing numerous contributors across multiple years, and the NEWS file documenting regular releases and fixes.

Limitations and Risks

Vulnerabilities Still Occur: The recent CVEs (CVE-2025-6019, CVE-2025-8067) show that despite active maintenance, security issues are discovered. This is normal for any software, but it means UDisks2 is not "perfectly secure."
Complexity Creates Risk: The daemon's broad functionality — mounting filesystems, managing loop devices, handling encryption — creates a large attack surface. shows loop device setup involves multiple validation steps, but as CVE-2025-8067 demonstrates, edge cases (negative indices) can be missed.

How to Evaluate Trust

Keep systems patched: Security fixes are released; apply them promptly
Review Polkit policies: udisks.xml.in:44-62 shows authorization is configurable—restrict who can perform sensitive operations
Monitor for updates: The project actively fixes issues when discovered
Understand the risk model: UDisks2 is a privileged daemon; treat it accordingly in your threat model

The project is reasonably transparent by open-source standards, but "trust" should be conditional on keeping it updated and properly configured.

Notes

The existence of CVEs doesn't indicate a lack of transparency — it indicates the project is actively maintained and vulnerabilities are being found and fixed. The real question is whether you trust the maintainers to patch issues promptly, which the evidence suggests they do.

UDisks2 does exhibit the appearance of transparency through public bug tracking and CVE disclosure, but the recent CVEs (CVE-2025-6019, CVE-2025-8067) demonstrate that vulnerabilities reach production despite these practices. The transparency is real but incomplete—it's reactive (fixing issues after discovery) rather than preventive.

The Transparency Mechanisms

The project does maintain public channels: udisks.xml.in:388-403 directs bug reports to GitHub, and NEWS:2796-2800 documents security fixes like CVE-2014-0004. This is genuine transparency infrastructure.
However, the infrastructure's effectiveness is limited. The loop device handler in validates that fd_num >= g_unix_fd_list_get_length(fd_list), but this check doesn't catch negative indices—exactly the vulnerability CVE-2025-8067 exploits. This suggests the validation logic was incomplete at release time, despite being reviewed code.

The Core Problem

The issue isn't dishonesty; it's that complexity defeats transparency. A daemon managing storage operations across multiple technologies (filesystems, loop devices, encryption, partitions) creates a large attack surface. shows mount option calculation and shows the Resize method — both are security-sensitive operations where edge cases can be missed.
Transparency here is more about admitting problems after they're found than preventing them beforehand.

Notes

The distinction matters for trust decisions. You can trust UDisks2 to patch vulnerabilities when discovered, but you shouldn't trust it to be free of vulnerabilities. The project's transparency is genuine but operates within the limits of what code review and testing can catch.

Last edited by igorzwx (Today 01:02:43)

brocashelm · Yesterday 23:47:13

Udisks2: Another Loss For Linux

Altoid · Today 00:16:42

Hello:

IgnorantGuru@ Udisks2: Another Loss For Linux wrote:

This effectively turns Linux into Windows, where users can’t do much from a command line, and even when you should be authorized to do something on your own system, that system denies you permission.

Indeed ...
Note the date on the post: March 11, 2012

This chap was bitching about this a whole five years before I started.
Imagine how bad things are now ...

Best,

A.

brocashelm · Today 00:30:25

@Altoid:

Indeed, and I appreciate what IgnorantGuru brought to us by means of SpaceFM and Udevil -- both of which I use with little problems on Daedalus. I don't have any Elogind or Udisks2 (thus no GVfs) running on any of my post-Beowulf Devuan installs. Very little (if even at all) Polkit shit (I use a YAD script for graphical root privileges in place of Pkexec). I installed the "dummied" Logind package (dummy-logind) to get around KDE and NetworkManager conflicts. With ConsoleKit2 and Seatd managing my Xfce sessions, I'm pretty much all set.

greenjeans · Today 01:39:35

Tempest in a teapot. As with most "security" risks i've seen lately, only applies to a multi-user system, and it assumes that if you go to the bathroom in a coffeeshop whilst online, that that coffeeshop is full of hackers who are just waiting for you to leave your machine unattended (and not locked) so they can rush over there and start looking through your files. Having to type a password to view your own files in another partition on your own machine of which you have sole access to, is retarded. Editing polkit fixes that nonsense.

If I had a dollar for every stupid thing that was done in the name of "security" i'd be rich. A lot of it is FUD, and frequently used these days as excuses for lack of quality code by second-rate coders (It's not a bug, it's a feature that we removed functionality, it's for your own good).

If someone were to somehow break in to my machine, you would not find:
1. Porn
2. Personal homemade porn (I have a sneaking suspicion that this is why some people are paranoid about security).
3. Passwords
4. My name, SSN, DOB, or any other personal info such as banking info

You could wipe the entire drive and I wouldn't lose squat. Everything I have that's important is permanently air-gapped. I don't use mail-clients, if I did I would have literally woke up this morning to a virus e-mail on my damned machine, instead it's on my mail providers server, and got promptly deleted and reported.

zapper · Today 01:55:05

@greenjeans not everyone is that intelligent. In usa, I heard recently that half of the public has a fifth grade education... just insane.

If true, this is why security considerations are so important to the vast majority of people I think.

As for udisks, dbus and other redhat garbage, there is a HUGE reason that Hyperbola ditches so much of that crap.

Overengineered crap makes lots of vulnerabilities and really bad ones at that.

This is one of those times I think, good. I am glad Hyperbola ditched this crap in plain english.

greenjeans · Today 02:01:30

Not a matter of intelligence zappy, just common sense.

Lol and even if someone got my banking info, wouldn't do much good, I don't have squat in the bank and I dumped credit 17 years ago, so my credit rating is like negative -0

laurie_dev1 · Today 03:01:09

Is it possible to not use dbus on devuan?
I would guess a lot of things would not work and be a bare bones type system.
Im pretty sure you could pin all dbus packages to -1 and see what can be installed, might give that a try on vm.

This quote from ignorant guru in regards to udisks2/gvfs plus many other so called advances in gnu/linux is spot on.

ignorant guru wrote:

it undermines the core philosophy of Linux, which is that programs interoperate using simple command line interfaces and text streams.

Udisks2/gvfs in my opinion has far too many layers of abstraction.

Last edited by laurie_dev1 (Today 03:02:41)

brocashelm · Today 03:52:39

@laurie_dev1:

It's possible to remove the D-Bus daemon and get a pretty lean desktop, but if you want every single part of it (e.g. libraries) gone, you'll pretty much have nothing to work with. I experimented with this in a VM, and it's pretty bleak if you do it. Dillo is the only "graphical" Web browser that actually does survive this purge.

There was/is an experimental Refracta ISO from the Beowulf era that removes as much D-Bus as possible, using SpaceFM with LXDE's panel in place of Xfce. Perhaps Fsmithred could upload it again for your curiosity.

zapper · Today 08:24:49

@greenjeans When I bring up intelligence, i am also talking about if they have common sense, so nice try.

Point being, common sense is lacking in USA. Otherwise certain people wouldn't have power. right now or since 2016.

zapper · Today 08:27:07

@brocashelm palemoon is buildable without dbus just so you know. I have done it many times before.

Yup.

Not sure about firefox and similar though.

steve_v · Today 08:59:02

only applies to a multi-user system

Yes, believe it or not those do exist and they do have more stringent security requirements than your personal machine. The "nothing but single-user desktop exists" blinkers everyone on this board seems to like wearing are extremely silly.
Then again, if you're administering a multi-user system and allowing people to plug in random storage devices then that's the real problem, not the software enumerating them.

If someone were to somehow break in to my machine, you would not find...

What they will find is your web browser storage, which will likely contain cached pages and login cookies even if you use 2FA and never "save" any passwords.
"I have nothing to hide" is a ridiculous non-argument, regardless of whether it's applied to security or privacy.

I don't use mail-clients

So webmail then? Guess what's in your browser storage...

it's on my mail providers server

Ahh, good old "somebody else is dealing with it" security-as-a-service.

Tempest in a teapot.

The above aside, I agree. Udisks itself is pretty irrelevant as an attack vector, noexec & co is a nothing-burger in most situations because nobody uses auto-run any more, and everything else requires physical control of the device and the ability to connect random storage, at which point you're cooked anyway.
Smells like AI CVE-slop to me.

Last edited by steve_v (Today 09:08:26)

brgs · Today 09:58:26

@brocashelm / @laurie_dev1

I got in a quarrel on another forum, when I asked how to shut up
Xorg about no dbus (no way, must recompile, don't do it, nothing will
work). So I switched it of and since then (2 years or so) still did not find
a single feature I use missing.

IMHO if someone creates a kind of fake-dbus that the libraries can connect
to and do nothing everything will be fine for now. Maybe a Preload Library
pretending to be libdbus could do the trick.

What does this thing even do?

--brgs

edit: typo

Last edited by brgs (Today 09:59:00)

brgs · Today 10:13:04

@greenjeans:

I really don't get what's so funny. There are a lot of places in
the world where you get in trouble for something on your
computer, perfectly legal three years ago, and the number of
this places is growing.

So it's fine if you are embarassed by porn and not by lack of
credit, but there is already stuff you can only do online that
requires you to type in - for example - your SSN (maybe not it
in the USA, i don't know about them.)

steve_v · Today 10:16:09

how to shut up Xorg about no dbus

Xorg doesn't use dbus, it uses unix sockets for IPC. You only need dbus if you enable [e]logind support, which is only needed for "rootless" (i.e. brokered permissions) operation and is a compile-time option.

must recompile

Uhh, so why not just do that then, rather than "quarrelling"? It's not rocket science, and no binary distro can please everyone with their choice of configuration.
Debian builds Xorg with logind support, and that pulls in dbus. Deal with it, or recompile to suit your taste.

if someone creates a kind of fake-dbus that the libraries can connect to

FFS, just compile the things without dbus, then they won't try to use it to begin with and "somebody" won't need to do anything.

What does this thing even do?

IPC, strangely enough.
Any modern DE will need some kind of IPC, the dbus spec is kind of a mess and everyone is doing their own random things with it, but it's what we have so it's what most projects use. Whether that's better than everyone having completely different solutions (e.g. dcop in kde3, corba in gnome) is a matter for debate.
There are dbus alternatives in the wild, but none of them have any real adoption.

Last edited by steve_v (Today 10:34:08)

brgs · Today 11:21:15

Xorg doesn't use dbus

No, but it asks for it every second and fills up the log with cannot connect.

Uhh, so why not just do that then, rather than "quarrelling"? It's not rocket science.

This was only the core of the problem. There is a configuration
option to disable dbus, it's off by default and you need to write
a Xorg.conf. The automatism is broken and will not be fixed, because
"you don't need an Xorg conf, Xorg configures itself". I forgot how to
write a Xorg.conf manually because I haven't done in 15 years, so I
asked how, then I got the answer: use -configure.

FFS, just compile the things without dbus, then they won't try to use it to begin with and "somebody" won't need to do anything.

I understand that this is the gentoo-aproach and you like that
system. But I did choose to use devuan.

Actually I didn't ask this in the first place. Brocashelm did, and I
made a suggestion.

And regarding the "quotemarks". Yes. Probably this somebody will
be me.

Wasn't the title of this subforum "freedom hacks?" I am sick of
software I have to recompile everytime a new version is out,
because someone decided I now need to use pipewire. Oh wait.
Somebody made a preload-library and now I still can use alsa.

There are dbus alternatives in the wild, but none of them have any real adoption.

Great. I don't want one. I want it switched off. There are other
ways to do whatever it's good for, most likely /bin/true.

steve_v · Today 11:47:33

There is a configuration option to disable dbus, it's off by default and you need to write a Xorg.conf.

Source? AFAIK there's nothing related to logind or dbus in xorg.conf, and there never has been.
Enabling or disabling logind integration is done at compile-time, by passing:

-Dsystemd_logind=false

to meson.

I forgot how to write a Xorg.conf manually

The xorg.conf(5) manual is in the same place it has always been.

I understand that this is the gentoo-aproach

Compiling software is not specific to "the gentoo-approach", and can be done on any distro that includes a compiler toolchain and development libraries... Which Devuan does.

But I did choose to use devuan.

So either use the Devuan packages with the options Devuan chose, or recompile them if you want something different. All the tools to do the latter are in the official repositories where they've always been.

I didn't ask this in the first place. Brocashelm did, and I made a suggestion.

Brocashelm pointed out that a lot of things depend on libdbus (because they were compiled against it), and you suggested an exceptionally ugly workaround that doesn't actually exist.
The correct approach is to recompile or patch the affected packages to not link against libdbus, on a case-by-case basis. Anything else is bound to end in disaster.

LD_PRELOAD hacks or stub-libraries and the like will cause problems, because sooner or later (probably sooner) upstream will use a function you haven't implemented or depend on a reply to a message you sent to /dev/null, and everything will blow up.

Better yet, somebody will use something that asks over dbus a question like "is this a container" or "what init system are we using" before starting a potentially system-trashing operation... And you propose just answering "true" every time? What could possibly go wrong?

Why go to all that effort with fragile half-arsed solutions, just to avoid rebuilding packages?

Wasn't the title of this subforum "freedom hacks?"

"Hacks" doesn't preclude recompiling to get the behaviour you want, and you have the "freedom" to do so.

I am sick of software I have to recompile everytime a new version is out, because someone decided...

If you write the software, you get to decide what options and dependencies it has.
If you package the software, you get to decide which of those are enabled.
If you just use the software, you get to complain ineffectually, and I get to give you shit for it.

I don't want one. I want it switched off.

You want a binary distro that caters to your specific whims and provides packages built just the way you want, with no effort on your part.
Spoiler alert: It doesn't exist, and it won't unless you make it. Some things need to be decided at compile-time.

Last edited by steve_v (Today 12:29:15)

fsmithred · Today 13:16:40

Here's an old discussion on installing devuan without dbus. Most of it still applies.
https://dev1galaxy.org/viewtopic.php?id=2158

The only nodbus iso I have available right now is the 32-bit refracta_13 (excalibur)
https://get.refracta.org/files/excalibu … 5_1239.iso

I put that on my 32-bit netbook and ended up adding dbus so I could install something. Poking around now, it looks like that something included audacious, abiword, firefox-esr, and yeah now I remember the real kicker - spacefm. Relevant to the OP, I like to use spacefm with pmount for mounting removable disks.

brgs · Today 13:57:32

Here's an old discussion on installing devuan without dbus. Most of it still applies.
https://dev1galaxy.org/viewtopic.php?id=2158

Interesting thread, thank you.

brgs · Today 14:13:05

And you propose just answering "true" every time? What could possibly go wrong?

No. That was ironic. On a second thought: If you run software that
initiates whatever you regard a system thrashing operation after
receiving nothing but a return value of zero, it might better be thrashed.

steve_v · Today 14:33:50

software that
initiates whatever you regard a system thrashing operation after
receiving nothing but a return value of zero, it might better be thrashed.

Oh dear, I guess we had better chuck dpkg in the bin then.
Here's a nice "replace $hated_thing with a stub that does nothing" package which breaks bootloader updates. I see that bug has still not been looked at, and the maintainer is still nowhere to be found. *Filed 2 years and 255 days ago*

While not directly comparable, it's exactly the kind of unexpected borkage that will ensue if we start intentionally breaking things, pretending services are available when they aren't, and lying to applications.

Last edited by steve_v (Today 14:38:02)

igorzwx · Today 14:39:47

In security, when everything focuses on the exposed, the greatest risk lies in what remains unseen. When a threat or system is exposed, it naturally draws scrutiny and defense — but the real risk often lies in what remains hidden: unpatched systems, shadow IT, unknown assets, or undisclosed vulnerabilities.

Removing D-Bus may create a false sense of security. While it reduces one attack surface, it can break system functionality and distract from real threats.

Why this is a trap:

D-Bus is foundational: It coordinates communication between system components (e.g., network management, power, Bluetooth). Removing it can cause instability or force insecure workarounds.
Security through removal ≠ security: Just because a service is gone doesn’t mean the system is safer. Attackers may exploit other vectors (e.g., direct IPC, file system races).
False confidence: Believing the system is “more secure” because D-Bus is gone can lead to neglecting actual hardening (e.g., access controls, logging, updates).

Security isn't achieved by stripping out critical components, but through proper understanding and control of the system.

Devarch · Today 14:45:37

USB automount is risky

steve_v · Today 14:48:13

Lay off with the ChatGPT Igor, it's obvious and it's tiresome. If we want AI security "advice" we can ask one ourselves without you reposting it.

Last edited by steve_v (Today 14:51:36)

igorzwx · Today 15:28:52

Disliking AI doesn’t entitle you to censor someone else’s posts.

The officially official Devuan Forum!

#1 Yesterday 23:23:13

UDisks2: Security Considerations

UDisks2: Security Considerations

#2 Yesterday 23:47:13

Re: UDisks2: Security Considerations

#3 Today 00:16:42

Re: UDisks2: Security Considerations

#4 Today 00:30:25

Re: UDisks2: Security Considerations

#5 Today 01:39:35

Re: UDisks2: Security Considerations

#6 Today 01:55:05

Re: UDisks2: Security Considerations

#7 Today 02:01:30

Re: UDisks2: Security Considerations

#8 Today 03:01:09

Re: UDisks2: Security Considerations

#9 Today 03:52:39

Re: UDisks2: Security Considerations

#10 Today 08:24:49

Re: UDisks2: Security Considerations

#11 Today 08:27:07

Re: UDisks2: Security Considerations

#12 Today 08:59:02

Re: UDisks2: Security Considerations

#13 Today 09:58:26

Re: UDisks2: Security Considerations

#14 Today 10:13:04

Re: UDisks2: Security Considerations

#15 Today 10:16:09

Re: UDisks2: Security Considerations

#16 Today 11:21:15

Re: UDisks2: Security Considerations

#17 Today 11:47:33

Re: UDisks2: Security Considerations

#18 Today 13:16:40

Re: UDisks2: Security Considerations

#19 Today 13:57:32

Re: UDisks2: Security Considerations

#20 Today 14:13:05

Re: UDisks2: Security Considerations

#21 Today 14:33:50

Re: UDisks2: Security Considerations

#22 Today 14:39:47

Re: UDisks2: Security Considerations

#23 Today 14:45:37

Re: UDisks2: Security Considerations

#24 Today 14:48:13

Re: UDisks2: Security Considerations

#25 Today 15:28:52

Re: UDisks2: Security Considerations

Board footer