Tomb mounting without sudo (Follow up on #186)

[Narrat]

This is some further looking into an idea that JP-Ellis wrote about in #186:
Quote:

"And one last point. Mounting currently is all done manually with mount; but have you considered using udevil mount or other similar tools which permits users to mount partitions without sudo?"

So let us gather some cli program names that help with mounts:

• bashmount
• ldm (lightweight device mounter)
• mountie
• pmount
• udevil
• udisks/udisks2
• udiskie

And look at them:
udiskie is an automounter which uses udisks, bashmount and mountie also rely on udisks.
udisks/udisks2 works with polkit and udev.
ldm and udevil interact with udev.
pmount states on his homepage: "pmount is a wrapper around the standard mount program which permits normal users to mount removable devices without a matching /etc/fstab entry."

So it comes down to udev(+ whatever magic needed), udisks/udisks2, ldm, udevil or pmount.

I leave udev aside. Dunno how easy it is to work with it, but in every case the result would be a separate program.

udisks/udisks2 works with udev and polkit and is somewhat tied to GNOME/GTK (depend on glib2), but should be the most available one. It should be noted, that the following part is in the manpage: "Additionally, this program is not intended to be used by scripts or other programs - options/commands may change in incompatible ways in the future even in maintenance releases. See the “API STABILITY” section of udisks(8) for more information."
Also it has fix mount points (/run/media/; with 2.1.5 alternatively with an option to mount under /media)

Dunno what pmount is doing. Didn't use it before

ldm is using udev and libmount. Didn't use it before

udevil is some mount helper to allow mounts without the need of root/su/sudo if suid is set. It interacts with udev to achieve it's behaviour.
Personally I don't have any experience with udevil. It is primarily used by the filemanager spacefm and it's creator didn't like existing tools (maybe simplified, but he wrote his opinions down in his blog).

---

Example of mounting a tomb without tomb and less sudo via udisks2:

lo=$(losetup -f)
udisksctl loop-setup -f secret.tomb
pass="$(gpg -d secret.key)"
echo -n -e "$pass" | sudo cryptsetup --key-file - luksOpen $lo secret
udisksctl mount -b /dev/mapper/secret

Where it asked for the $USER PW.
So the remaining sudo call would be to cryptsetup (else it would fail with permission denied error). Dunno if this can be avoided. Should be possible since there exists tools like cryptobox and cryptmount and skul and maybe one of them is doing it entirely without su rights. (Need to check that)

---

So far from me. I hope this has some information included and opens discussion how to get tomb using less su rights.

[jaromil]

ACK. Thanks for the roundup! Generically speaking I'm incline to stay away from gtk/gnome and such stuff that is not commonly found on headless servers and is made by people that have poor concerns about minimalism and security.

[jaromil]

Also check tcplay, may be another alternative to cryptsetup not requiring su rights. Using udiskctl when available seems reasonable.

[Narrat]

Right, forgot about tc-play.

Well, had a look at skul and cryptmount.
The first is using super user rights, so in that case similar to tomb.
cryptmount needs superuser rights to configure a fstab like file (cmtab) after that the normal user can mount and umount a dm-crypt fs. So not really the right idea for including but maybe an external wrapper.

What about this PAM stuff? I don't know anything beside this stuffs exists.

Edit: cryptobox offers no solution either. Early check for UID 0. If not it's failing

[jaromil]

Yes, PAM and polkit are the place to look into I guess, but they are very convoluted.
Also I'm not sure they offer interfaces to device-mapper/dm-crypt in addition to the usual mount and init stuff.

[Narrat]

Well with pam_mount (http://pam-mount.sourceforge.net/) there exists something like that --> http://pam-mount.sourceforge.net/mount.crypt.8.html

And back in 2006 there was this attempt to allow normal users to call cryptsetup mount http://osdir.com/ml/linux.kernel.device-mapper.dm-crypt/2006-02/msg00003.html

[jaromil]

As mentioned in the 2006 post, I see is also the case for mount.crypt, loop devices require root. I understand this limitation is inherent to the way loop devices are treated in linux, rather than a dm-crypt issue. Not sure if we can work on that, but the rest is doable and limiting privilege escalation is a good improvement.

EDIT: if this works udisksctl loop-setup -f secret.tomb and then mount.crypt works on the loop, then it may be solved. This surely requires extensive testing...

[Narrat]

Yeah. Simply using mount.crypt fails with missing rights because of loop devices.

Simple testing the combination udisksctl + mount.crypt didn't work. If I point mount.crypt to the loop device it exits with the message

crypt_init: Block device required

Maybe I missed something to do

In that way it sounds easier to write it's own mount sub command as extra with suid set, but that doesn't sound sane :D

[otizonaizit]

Hi. I was using my own set of shell scripts until I discovered tomb today. There is a version (0.9.99-alpha-1) of pmount (see http://metadata.ftp-master.debian.org/changelogs//main/p/pmount/pmount_0.9.99-alpha-1_changelog ) available in Debian experimental which allows for mounting luks encrypted files using loop devices without root and without sudo. You only need root once to create the encrypted file with cryptsetup, but after that everything works without root. So maybe it shouldn't be default, but it would be nice if tomb could use it when available...

[jaromil]

Interesting! forward looking! thanks. I'll try the 0.9.99-alpha sounds very fringe.
accepting bets if the go 0.10 or 1.0... you never know ;^)

[Narrat]

If they're ever doing it :P
This is from 2011, but nice that it includes it. Hopefully it's working

[jaromil]

perhaps we should include and start hatching pmount 0.99-alpha in case is left unmaintained?

[otizonaizit]

Yes, looking at the history of the Debian package, given that the Debian maintainer seems to be upstream too (https://pmount.alioth.debian.org/ and http://anonscm.debian.org/cgit/pmount/pmount.git/) and that development seems to have stalled in 2011, taking over maintenance of pmount would be a huge service to the community of non-gnome non-unity non-kde command line users :) On the other hand, given that pmount is installed with set-uid and that it does not belong to the list of packages installed by default in a Debian system, I am not sure there is a real advantage in keeping on with its maintenance: a user without sudo is not going to be able to get pmount installed without root either...

[jaromil]

The scenario of a user using tomb on a system where he/she has no access (direct or indirect via sysadmins) is to be excluded fro Tomb. I believe it will never be possible.

But having pmount suid or as sudo nopasswd for some users is useful in case a sysadmin wants to provide his system's users with access to tomb without making them root on the machine. With Tomb we are contemplating this scenario since long already and I'm looking forward to pmount to represent an alternative approach.

Other modifications suggested in this issue are also possible improvements.

[hellekin]

Message sent to @fourmond regarding �pmount.

[brianmay]

pmount has a -p option, which allows it to mount encrypted filesystems without root:

-p file --passphrase file
    If the device is encrypted (dm-crypt with LUKS metadata), read the passphrase from specified file instead of prompting at the terminal. 

Shame if development has stalled.

[chri2]

I hope this has some information included and opens discussion how to get tomb using less su rights.

• Did anybody look into how mount, losetup, cryptsetup and such behave inside a user and mount namespaces under linux?
• Would it be a solution if users who are allowed to use tomb could call sudo tomb without password? Tomb could check on execution if the user is allowed to sudo tomb without password and call if needed operations by calling itself with appropriate parameters.
  • there sure is some kind of security implication: the script needs to be in a place where it can only be altered by root. On the other hand: which user would check the script each time she types her password when using calling a tomb operation needing root?
  • This would need discussion and a good documentation of the risks.
  • On many systems doing things like letting users call scripts using sudo is already used, the risks are known and the attack surface by adding tomb wouldn't get any much bigger.

[chri2]

I just had another idea: use user mode linux to run the smallest possible paravirtual machine to let a user create a filesystem.

If it worked (I didn't dive deeper into it, yet), it could be completely optional: if the user wants and their environment provides the needed software a script could setup and start a user mode linux. Inside this minimal system the user is root and can use the filesystem tools and loop devices without being root on the host system.

Maybe this could even be a wrapper to tomb to not bloat its code?

[Narrat]

Namespaces may be an interesting idea to look further into.

But dunno about user mode linux. In and itself it may be the smallest vm, but you need to have a fitting kernel (in regards of modules) installed. And as far as I looked, the main kernel of a distribution cannot be used.
And additionally a block device file with all the tools needed. Although it seems to be possible to use the existing file system, the question would be if one should be doing this (because of root)

[chri2]

Namespaces

As far as I remember: they do not help. Loop devices do not support namespaces and if you can losetup you can set up or delete any of them and therefore need to be root.

Maybe this is another option for the future: https://www.libguestfs.org/guestmount.1.html
(https://im-in.space/@etam/110433729678599777)