[dm-crypt] secure use of cryptsetup by non-root

[dm-crypt] secure use of cryptsetup by non-root

[JT Morée]

Hi all,

# TLDR;

1) Is 'secure use of cryptsetup by non-root' a supported use case?
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@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: secure use of cryptsetup by non-root

[Milan Broz]

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@saout.de
> To unsubscribe send an email to dm-crypt-leave@saout.de
> 
_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: secure use of cryptsetup by non-root

[Peter Grandi]

> 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).

That is sad, because in theory having access permissions to a
block device special file ought to be enough, but some people seem
to think that the UNIX/POSIX permissions system is "insecure" and
thus add their own special-case restrictions. It is part of the
same thinking that DM block device special file cannot be created
other than in '/dev/mapper', to be "helpful".

> 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.

  $ grep xxx /etc/sudoers
  xxx             ALL=NOPASSWD:/sbin/cryptsetup create xxx-sdc5 /dev/sdc5, \
		      NOPASSWD:/sbin/cryptsetup remove xxx-sdc5
  $ id -n -u
  xxx
  $ sudo /sbin/cryptsetup create xxx-sdc5 /dev/sdc5
  Enter passphrase for /dev/sdc5:
  $ sudo cryptsetup remove xxx-sdc5

Note: some "secondary" details omitted :-).

That for statically defining which block devices can be used by
which user, something like a daemon like the 'libvirtd' one can be
used for more dynamic definitions.

> (It is tricky with only cryptsetup, but it is possible through
> using null cipher with block device.)

That could be disabled by recompiling the kernel, not that it is
essential given the above.
_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: secure use of cryptsetup by non-root

[Milan Broz]

On 08/08/2021 20:43, Peter Grandi wrote:
...
>> (It is tricky with only cryptsetup, but it is possible through
>> using null cipher with block device.)
> 
> That could be disabled by recompiling the kernel, not that it is
> essential given the above.

Then just setup an encrypted device with a known key and use
userspace app to reverse it by running encrypt/decrypt operation.

There are more tricks, it is not secure.

Milan
_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: secure use of cryptsetup by non-root

[JT Morée]

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

RIGHT..... SO

>> 2) Can we add FAQ entries for this?

see original email for nicely formatted FAQ questions and answers or I can put them somewhere else if needed.
_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: secure use of cryptsetup by non-root

[Peter Grandi]

> 1) Is 'secure use of cryptsetup by non-root' a supported use case?

It would be interesting to read an explanation of how you think
that *direct* use of 'cryptsetup' by users, instead of through
something like 'sudo' or by request to a daemon running as
'root', could be "secure", given that there are two cases:

* The DM block device is not going to be used as a filesystem
  container, but as if it was a file, and then there is no big
  reason to use DM at all but perhaps in some special cases.

* The DM block device is going to be mounted as a filesystem,
  and thus user can put into it any inodes they want, such as
  for 'root'-setuid executables or arbitrary device special
  files, and then the whole system security is compromised.
_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de

[dm-crypt] Re: secure use of cryptsetup by non-root

[JT Morée]

>> 1) Is 'secure use of cryptsetup by non-root' a supported use case?
> It would be interesting to read an explanation of how you think that *direct* use of 'cryptsetup' by users, ... could be "secure", ....

Are you asking for justification for why this is a valid use case or asking about the technical limitations for said use case?

For the latter, that's what we are discussing.  Allowing non root access to encrypted storage may take a lot of work but since this and upstream limitations are open source we could make it happen. To do that requires understanding, discussion, planning, etc.--even if I end up doing it all myself.  The use case is END USER + ENCRYPTION.  cryptsetup, LUKS, device mapper are means to that end.  Direct use of cryptsetup is only 1 possible path.

Just in case you are asking the former:  allowing non root users secure access to 'features' is generally a way to avoid something like the windows security model where almost everything has to be run as admin to get anything done.  

-- 
JT
_______________________________________________
dm-crypt mailing list -- dm-crypt@saout.de
To unsubscribe send an email to dm-crypt-leave@saout.de