public inbox for dm-crypt@saout.de
 help / color / mirror / Atom feed
From: Milan Broz <gmazyland@gmail.com>
To: "JT Morée" <moreejt@yahoo.com>, "dm-crypt@saout.de" <dm-crypt@saout.de>
Subject: [dm-crypt] Re: secure use of cryptsetup by non-root
Date: Sun, 8 Aug 2021 15:16:51 +0200	[thread overview]
Message-ID: <3999b2cc-c1da-a9ca-146b-ee457171f934@gmail.com> (raw)
In-Reply-To: <1876586861.281618.1628426928218@mail.yahoo.com>

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

  reply	other threads:[~2021-08-08 13:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1876586861.281618.1628426928218.ref@mail.yahoo.com>
2021-08-08 12:48 ` [dm-crypt] secure use of cryptsetup by non-root JT Morée
2021-08-08 13:16   ` Milan Broz [this message]
2021-08-08 18:43     ` [dm-crypt] " Peter Grandi
2021-08-08 19:48       ` Milan Broz
2021-08-09 12:03     ` JT Morée
2021-08-08 18:06   ` Peter Grandi
2021-08-09 12:27     ` JT Morée

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3999b2cc-c1da-a9ca-146b-ee457171f934@gmail.com \
    --to=gmazyland@gmail.com \
    --cc=dm-crypt@saout.de \
    --cc=moreejt@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox