Re: Using Windows and bitlocker

On 19 Jun 2025 11:57 -0400, from [email protected] (Mark Foley):
> [...] I've downloaded and installed cryptsetup 2.7.5. [...]

Most Linux distributions include cryptsetup in their repositories; you
should not need to download and install it manually through
out-of-band means. Using the distribution's packaged version is
generally better unless you are working on the cryptsetup code; you
get updates through the distribution's normal update process, and you
don't risk unknowingly introducing incompatibilities between for
example the kernel, libcryptsetup, and cryptsetup.


> I have a couple of empty partitions ready to test with, and I believe I can set
> up an encrypted partition using 'cryptsetup luksFormat' and 'cryptsetup
> luksOpen' per numerous examples I've seen.
> 
> Questions:
> 
> Is cryptsetup the right choice for Windows/Samba access of entrypted drives/
> partitions on Linux?
> 
> If so, do I need to use BitLocker from Windows?
> 
> If so, How do I set that up with cryptsetup?

I'm afraid you are confusing two somewhat different, related concepts,
and that this is a significant source of your confusion.

Microsoft's Bitlocker, LUKS on Linux, VeraCrypt, and others are
examples of _full-disk encryption_ (FDE) solutions.

Full-disk encryption is mainly about protecting _data at rest_. The
typical example is if someone steals a laptop, or an external storage
device used to hold backups. (It's also useful in other situations, of
course.)

Once the system is booted and the volume is unlocked, full-disk
encryption is generally designed to allow access to the storage device
as if it was not encrypted in the first place. With LUKS, this is done
through Linux device mapper dm-crypt mappings, controlled using the
cryptsetup tool and its underlying libcryptsetup library. (Bitlocker
is a bit of a hybrid as it integrates with NTFS file encryption and
access control on supported Windows systems as well as typically use
the system TPM for transparent volume decryption.)

Using full-disk encryption _provides the capability_ to ensure that if
someone for example steals the file server, the thief won't be able to
access the files stored on it because they cannot open the volume.
Without the key material, it looks like random data; there is no way
to know whether that data represents a design for a new fighter jet or
a photo of a kitten.

What you are more likely looking for here is _access control_.

Access control works on a directory/folder or file level, and is about
which authenticated users (if any) can access which directories or
files. Windows ACLs and Unix-style file permissions are examples of
how access control can be manifested.

Access control in an environment like you describe can be configured
for example by restricting certain shares in Samba to certain users or
groups, depending on who should have access to what. (It's been ages
since I did anything of the sort, and this mailing list is the wrong
place to discuss how to do that.) The Samba server software will then
(assuming it is implemented and configured correctly) enforce those
restrictions on any accesses through it. However, Samba needs to be
able to read (and write, if anyone has write access) everything for
this to work.

Correspondingly, Samba essentially doesn't concern itself with the
underlying storage stack, including LUKS; it operates on directories,
which may be a part of one, all of one, or contain a combination of
several file systems.

So, _ignoring_ the tooling: _what's your goal?_ At-rest protection,
access control during use, or both?

-- 
Michael Kjörling
🔗 https://michael.kjorling.se