IgnorantGuru's Blog

Linux software, news, and tips

Ubuntu To Dump Nautilus – Wants Your Input

In the latest sprint away from all things Red Hat, Ubuntu is planning to develop its own file manager and is asking for feedback. From Phoronix:

The latest piece of the desktop Linux stack that Ubuntu developers are planning to replace with their own home grown solution is a file manager. For likely inclusion into Ubuntu 14.10 would be a new Ubuntu file manager to replace GNOME’s Nautilus. Users and developers of Ubuntu are growing increasingly unhappy with the direction of Nautilus… Oliver Grawert is currently seeking feedback on the requirements and other sought after features of the new default file manager.

While Ubuntu’s likely file manager doesn’t excite me, the discussion is interesting. And it was good to see SpaceFM and udevil raised in the discussion. Isn’t it time for file managers to support ad hoc commands for mounting and other tasks, instead of binding users to one set of hard-coded system tools?

February 2, 2014 - Posted by | News

10 Comments

  1. Well, it would be ok for me to mount things the same in every file manager, if the system tools used are a device manager and fuse or bind, lol

    Comment by Theodore | February 2, 2014

  2. Is there a good article (among your past blog articles or elsewhere) which you’d recommend as a primer for someone (like me) who is not well-versed in the technical and security differences between udisks and udevil and pmount, pros and cons of their approaches, SUID/etc, and so on? And whether changing to udevil from what a distribution gives by default is a transparent “it just works” kind of thing or if many various programs (other than SpaceFM of course) are likely to cease working? (Or does one use it “in addition to” instead of “instead of” the existing default system?)

    (Apologies if this is too lame/newbie a question…) :)

    Comment by russ | February 3, 2014

    • > Is there a good article (among your past blog articles or elsewhere) which you’d recommend as a primer for someone (like me) who is not well-versed in the technical and security differences between udisks and udevil and pmount, pros and cons of their approaches, SUID/etc, and so on?

      Well this is a large topic but I can give you the summary. Using udisks starts a daemon (udisksd) which runs as root continuously. It uses consolekit/policykit (or upcoming systemd) for authentication, which involves sets of rules and various methods to determine if a user is logged into a console or logged in remotely, and what that user is allowed to mount, etc. Once it authenticates your action, it then runs mount as root to mount the device. Ostensibly this approach is done for more precise control and security. In practice it adds a lot of complexity to the security of the system, and causes breakage. As to how secure it is, that is not a simple matter to evaluate. You’d want to read the technical approaches used and evaluate them. It’s a complex system so understanding and using it effectively is not trivial. Overall I don’t like their approach, and its poorly designed and maintained IMO. And I know much of the udisks source code from the inside out.

      Otoh udevil, like pmount, is a program installed SUID. This means that when a user runs it, it automatically runs as root, as if the user used sudo to run it. No daemon is left running as root. SUID programs gained a bad reputation because of improper use. If the program allows the user to do a wide range of things, the user may be able to gain root priviledges on the system. But that only applies to poorly designed and implemented SUID programs. For example, everyone has at least one SUID program on their system already: passwd. When you run passwd, it always runs as root. This demonstrates that SUID is a valid approach to security if done carefully and appropriately to the task.

      You’ll find various discussions of SUID and how to write such programs effectively, and plenty of debate, somne of it ill-informed. Basically since the program runs as root, it must limit itself and what the user can do to a very narrow set of actions. SUID programs can’t be written sloppily, they have to be built like tanks, especially the command interface and memory management, or they can indeed compromise the whole system. This is why some users baulk at them, and it has become something of a knee-jerk reaction to SUID. You certainly don’t want a buggy, careless SUID program installed on your system.

      When designing udevil, I researched the daemon vs SUID approaches, and decided that SUID best fit the task and security requirements. Having a daemon running lots of code as root, like udisks, can also create problems. No approach is 100% – the result largely depends on the quality and testing of the code involved. Personally, I feel more comfortable with udevil than with udisks.

      As an SUID program, udevil takes various stringent precautions. First, it immediately drops its root priviledges when you run it, such that almost all of its code is run as a normal user. This greatly reduces security implications. All it does as root is what it must, such as running mount. It also scrubs the environment, removing almost all environment variables – another source of potential exploits. And it parses the command line with precision, validation, and intolerance, preventing users from injecting anything malicious into its memory space. What you can tell udevil to do is tightly limited. udevil.conf is part of this mechanism, allowing the admin to control what users can do with udevil. In addition, udevil.conf allows you to add your own authentication scripts into its checking, so you can eg add consolekit authentication to udevil as well (although this setup would be rare and requires some custom scripting).

      So if properly configured, I consider udevil/pmount to be at least as secure as udisks for the typical Linux user, probably moreso in actual practice. If you’re running a multi-user system with remote access and so forth, you may have more particular access concerns to address via more complex authentication schemes. But unless you know why it doesn’t suit you, udevil or pmount should be a reasonable solution to mounting, and they’re widely used by knowledgeable users. pmount for example has been in Debian’s repos for years (udevil is almost there), and Debian doesn’t include programs with known security exploits. They also get a lot of review and hard use in Debian. pmount has had a few potential issues over the years that were corrected, but nothing major. udevil thus far has an unblemished security record and has been reviewed for exploits and problems. Prior security concerns in pmount and other programs were also reviewed, and udevil was hardened against those exploits where needed. So you can say udevil has learned from years of SUID and mount program experience.

      Of course any program can have unknown bugs that affect security, including udisks. I would say udisks code is buggy in general and rapidly changing, so that doesn’t bode well for security. udevil changes slowly, and is relatively short and simple. There are less places for it to go wrong.

      This stackexchange question/answer goes over some of the approaches to user mounting, with links to some articles. You’ll notice it lists both udisks and pmount in ‘The mostly secure’ section. And you’ll also notice that the ‘will be secure someday’ section (user namespaces) lists a serious root exploit in the kernel from a year ago – an example how more complex and rapidly changing systems have their share of problems too, even if they are sold to users as ‘more secure’.

      > And whether changing to udevil from what a distribution gives by default is a transparent “it just works” kind of thing or if many various programs (other than SpaceFM of course) are likely to cease working? (Or does one use it “in addition to” instead of “instead of” the existing default system?)

      udevil can be installed on any Linux system with udev, and will coexist happily with any other programs, such as udisks, consolekit, and systemd. It doesn’t use or interfere with these at all. So if you install udevil, you’ll be able to mount devices using either udevil or udisks. Each will have its independent set of rules. SpaceFM, once it sees udevil installed, will use it by default, which is why you’ll hear the common ‘I installed udevil and now mounting is working’. udevil is a quick fix for udisks configuration hell, which is one of its purposes. SpaceFM will also use pmount before udisks if installed (because pmount is more trouble-free).

      Whether you can also then remove udisks and consolekit/policykit from the system depends on what you’re using that depends on these. For example, many file managers have udisks as a required dependency. If you remove it, they will be removed. In some cases you can hack udisks out or disable the daemon, and some apps will mostly work, except for mounting. As for consolekit/policykit, again it depends on what uses them (such as NetworkManager). Your package manager will know.

      Most users who install udevil leave udisks intact, so they can run other software that depends on it. udevil is there for SpaceFM’s use, devmon’s use, and command line/script use. Some users also then create a udisks-, systemd-, *kit-free system. Even dbus can be removed when using SpaceFM and udevil or pmount.

      Comment by IgnorantGuru | February 3, 2014

      • Thank you very much for that quite helpful (and fast!) response! I appreciate it.

        Comment by russ | February 3, 2014

        • The developer of Zulucrypt had an interesting reply as well. The udisks approach of running a root daemon and accepting commands via dbus has plenty of potential problems, as this udisks security bug shows. That bug is over one year old and Zeuthen has taken no action on it (or from what I see, has not even replied).

          Are most users concerned that someone will log in remotely and maliciously unmount their mp3 player? I think not. Most users want a system that can mount removable devices reliably while providing a simple, secure policy enforcement scheme they can actually understand and control. The entire udisks approach is highly inappropriate for most users, and was never engineered for them in the first place.

          In open source, you can’t lock people out of the code like you can in Windows. But you can make the system so complex that no one can control it at a lower level without being a developer with lots of time to spare. I think ultimately that’s what this is about. And the systemd tool stack will likely eventually be used for DRM and other restrictive technologies (just as HAL was).

          Comment by IgnorantGuru | February 4, 2014

  3. Offtopic:
    It is now final. Systemd has won the Debian TC vote.

    https://lists.debian.org/debian-ctte/2014/02/msg00405.html

    Comment by Zoopy | February 11, 2014

    • Man, this one is really great: “NSA operation ORCHESTRA: Annual Status Report” by Poul-Henning Kamp, FreeBSD developer, at Fosdem:

      [video src="http://video.fosdem.org/2014/Janson/Sunday/NSA_operation_ORCHESTRA_Annual_Status_Report.webm" /]

      Comment by Zoopy | February 12, 2014

      • Wow, EVERYONE SHOULD WATCH THAT. He’s my new hero. Had my doubts at first, thought he was naive-as-usual, but he went into some very subtle stuff and presented it very clearly.

        That IS Red Hat, to a tee! This is exactly what I see, and he explains it better than I can. He’s telling you how Linux is really engineered, forget the BS in forums.

        Comment by IgnorantGuru | February 15, 2014

  4. http://www.markshuttleworth.com/archives/1316

    Broken by design: systemd http://ewontfix.com/14/

    Comment by lennart | February 15, 2014

    • Thanks, that ‘broken by design’ article is excellent. And notice how short and clear it is, compared to the long BS-riddled tomes people write in favor of systemd. I’m not an init system expert, but I have seen first-hand what Red Hat developers have been up to in Linux in general, and they’re turning it into a complex, oft-broken, exploit-riddled system, a la Windows. I would think any fool could see this, but obviously not.

      It is myth that there is some debate happening over systemd. There is not. The decisions were made long ago, and anyone who doesn’t do what Red Hat DICTATES will come under so much pressure in various forms that they will cave, at least in terms of large entities like Debian. You are being informed of changes being made. Period. Scream all you want. And they know how to create and rally fanboys to make it look otherwise – look at all these idiots running to support and argue in favor of multi-billion dollar corporations hacking apart and destroying a free OS. Such people are so easily manipulated in their opinions that they’re a danger to everyone, including themselves.

      It is another myth that large corporations like Red Hat, and all they represent, care anything about your server or desktop security. Does Microsoft create secure systems with all their resources, or do they create buggy, unstable crap that undermines it routinely? Do they address problems brought to their attention or ignore them? How is it really engineered, and why?

      There are very dark undertones to all of this, but in my view people today are witless. They’re completely trained to accept whatever the corporate world hands them and never even think of doing for themselves. Further, many are hybrid windows/linux users, so they have forgotten what a real OS even looks like. They don’t even notice these changes. Linux crashing like Windows will be normal to them.

      Now developers and packagers will waste YEARS and millions of cumulative hours changing init systems. Then they will be locked into fixing and maintaining a willfully broken system. Forget any other kind of development taking place – no one will have time. And this is classic Red Hat – they are always keeping everyone dancing like this, trying to keep up with their breakage and endless, shallow changes. This effectively stops geniune progress.

      Further, it should be painfully obvious that Red Hat wants PID 1 because of DRM. They don’t want YOU to control your system or have free access to your own devices and peripherals. They will decide what you can and can’t do with your hardware. (Anyone who has used udisks for any period of time should recognize this pattern, but pattern recognition doesn’t seem to be a strong point. Most tech people are like children in terms of being manipulated and naive.)

      The good news is that Red Hat is becoming so dictatorial and ugly that it will drive some people to develop alternatives. But these will likely remain in small fringe areas. Prepare yourself – Linux is being engineered to be a steaming pile of shit.

      As I already said, if Debian, Ubuntu, and others were smart (they are not, they are subjugated morons), they would develop a packaging system that doesn’t depend on any one init system, but uses what the admin has installed. IOW, create choices in init systems. This would take work, but would help to free them from what Red Hat is creating, and the way they own Linux. But Red Hat simply won’t permit this to happen on any large scale.

      Comment by IgnorantGuru | February 15, 2014


Sorry, the comment form is closed at this time.