Re: secure use of cryptsetup by non-root

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 08/08/2021 14:48, JT Morée wrote:
> Hi all,
> 
> # TLDR;
> 
> 1) Is 'secure use of cryptsetup by non-root' a supported use case?

If you mean "allow all cryptsetup users to be able to activate device", then it is definitely not secure.
It works, but it would be major security hole in your system.

We need root for activation of device-mapper device (this requires CAP_SYSADMIN, it is basically root).

If you allow any user to access device-mapper (and sudo cryptsetup is just one way), you will allow
these users to access and modify *all* block devices in your system.
(It is tricky with only cryptsetup, but it is possible through using null cipher with block device.)

Do not do that.

Use known mechanism which allows to activate specific device by user, either by using udisks
(that usually allows to use to map encrypted flash drives) or perhaps systemd units can be setup for it (I guess).

Milan

p.s.
This is not problem with cryptsetup but with kernel device-mapper that has no way to specify private
devices or to properly use namespacing.


> 2) Can we add FAQ entries for this?
> 
> # Details
> 
> I am working on the use case to grant access to cryptsetup and LUKS devices to non root users but not allow them to access each other's devices or system luks devices ( /root and /home).  
> 
> If I grant sudo access to non root users they could run cryptsetup on any device.  This is a security hole and undesired.
> 
> I started working on this and recently posted an issue:  https://gitlab.com/cryptsetup/cryptsetup/-/issues/658
> 
> I ran into security problems with /run/cryptsetup and device mapper.  
> 
> In summary, even if I grant specific permissions on specific devices to specific users (using udev rules or whatever) cryptsetup still requires privileged system folders such as /run/cryptsetup for some operations.  If I grant the non root users access to /run/cryptsetup it is also a security hole.
> 
> 
> # FAQ
> 
> This use case comes up from time to time.  Can we add it to the FAQ?
> 
> * 1.9 Can cryptsetup be run without root?
> 
> Elevated privileges are required to use cryptsetup and LUKS.  Some operations require root access.  There are a few features which will work without root access with the right switches but there are caveats.
> 
> * 1.10  What operations absolutely require root access?
> 
> Device-mapper requires root and cryptsetup uses device mapper to manage the decrypted container.
> 
> * 1.11 What are the caveats when running as non root other than device mapper?
> 
> The first issue that you will run into when running without root is that file locking is managed in /run/cryptsetup.  You may use --disable-locks but cryptsetup will no longer protect you from race conditions and problems with concurrent access to the same devices.
> 
> * 1.12 What can I do if cryptsetup is running out of memory?
> 
> Memory issues are generally related to the key derivation function.  You may be able to tune usage with the options --pbkdf-memory or --pbkdf pbkdf2.
> 
> _______________________________________________
> dm-crypt mailing list -- dm-crypt@xxxxxxxx
> To unsubscribe send an email to dm-crypt-leave@xxxxxxxx
> 
_______________________________________________
dm-crypt mailing list -- dm-crypt@xxxxxxxx
To unsubscribe send an email to dm-crypt-leave@xxxxxxxx




[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux