0

Are there readily available packages on linux that provides an encrypted container that everyone can write to without knowing the password? We want each user to submit their works at the end of the day then wipe the machine clean. A user should not be able to access the data from previous users. We look at LUKS, EncFS, ... but it seems the container need to be unlock with a password before it can be write to. And if a hacker get in they may be able to access data on the container.

2
  • To encrypt something, you need a key. Usually that would be derived from a password (or generated randomly and protected with another that's derived from a password). You could create a new key each time, and protect the encryption key with public key encryption (the exact way PGP/GPG works), so they wouldn't need to know the encryption key. But they'd still need to be able to save the data somewhere, which might imply also being able to overwrite other entries.
    – ilkkachu
    Commented Dec 25, 2020 at 14:12
  • 1
    But since you say you want to wipe the machine clean, where would the data be stored in? If over the network, then why not have the server deal with access control, instead of relying on local authentication?
    – ilkkachu
    Commented Dec 25, 2020 at 14:13

1 Answer 1

1

A container protects the outside of the container from the inside. It does not protect the inside of the container from the outside. If you want user Alice not to be able to access the data of user Bob, then Alice must not have privileged access to the host. This means that Alice must not have root (“sudo”) access to the host machine, and that she must not be in physical control of the host machine (if she's physically in front of it, there must be some way to prevent her from doing things such as pulling out the hard drive).

If Alice only has user-level access to the host machine, ordinary Unix permissions are enough to protect Bob's data. Just give everyone a separate account. Containers and encryption are irrelevant.

If Alice has privileged access to the host machine, containers and encryption won't help you, since Alice can arrange to do anything that Bob can do, including reading Bob's data. It doesn't matter how Bob accesses his data: since Alice has privileged access, she can do it, too.

It sounds like you want users to be able to use client machines (with a single user using each machine at a time) and not see other users' data. So don't store their data locally: store it on some central server. Containers are not useful for this from a security perspective, but they may make deployment easier (which is the main motivation for containers anyway). Encryption is not particularly useful, but if you aren't storing anything locally except for temporary files that don't outlive a user's session, you can gain some benefit from encryption. Create two partitions: a system partition and a data partition. Mount the system partition read-only except while doing upgrades. Encrypt the data partition with a randomly-generated key that is re-created at the beginning of each session (or at boot time, and reboot the machine when a user logs out).

1
  • An analogy would be we have a room (computer) with a USPS-like dropbox (write-only encrypted volume). Each day a person enters the room (login) and do his work. At the end of the day the person dumps all his papers (files) into the dropbox, and left (logout). Next day, the same person or someone else comes and does the same. The key (password) is own by the big boss, who comes once a month to retrieve and empty the content of the dropbox. A thief or a worker cannot retrieve papers from the dropbox.
    – Chu Bun
    Commented Jan 14, 2021 at 19:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .