Comments (3)
In cases with multiple ext4 (with encryption enabled) mounted, we could potentially choose the "wrong" salt, i.e. a salt originating from from another FS than the one containing a specific encrypted directory. In the worst case, the salt used for setting up an encrypted home could originate from an external hard drive, rendering it inaccessible if the drive is not present. We thus deemed using an explicit salt would be more robust and less confusing for users with multiple ext4 mounts.
I definitely should have documented this more clearly somewhere (preferably in some merge/commit message).
Would you accept patches that re-introduce EXT4_IOC_GET_ENCRYPTION_PWSALT and iterating over mtab?
Only on the following conditions:
- the user should be able to choose the FS from which the salt is retrieved
- for setup, the
e4crypt
tool should also allow you to make this choice (it's been a long time and my memory is hazy, but I don't remember such an option) - using the
ioctl
call should be disabled by default (at least for the time being)
Slightly related side-node: pam_e4crypt's README currently stats that "Users must provide a salt (up to 16 bytes)". This is not entirely correct, e4crypt is able to handle salts of much larger sizes. Only the salt stored in the superblock and returned by the ioctl() is 16 bytes in size.
e4cryp
t may not have this limitation (any more), but pam_e4crypt
(stll) has.
Please take note that I'm quite tardy when it comes to do my job as a maintainer. I intended to work on this more for a long time now, particularly to set up some proper tests, but somehow I always got stuck on some minor detail. Hence I may be quite slow or even reluctant to incorporate new changes. In fact some changes already started piling up. So... be warned that at the moment, working on this may turn out to be rather frustrating for you.
from pam_e4crypt.
In cases with multiple ext4 (with encryption enabled) mounted, we could potentially choose the "wrong" salt, i.e. a salt originating from from another FS than the one containing a specific encrypted directory.
That can't happen if you simply create keys/policies for every ext4 filesystem on login. Or am I missing something? If not, then simply iterating over mtab and inserting a key generatied with every ext4 superblock-salt should do the trick.
- the user should be able to choose the FS from which the salt is retrieved
See above: I do not think this is necessary. And if it is indeed not necessary, then there is one less option to ask the user, which is always good.
e4cryp
t may not have this limitation (any more), butpam_e4crypt
(stll) has.
I don't think so: pam_e4crypt currently uses EXT4_MAX_SALT_SIZE
, which is defined, at least on my system, in /usr/include/ext2fs/ext2_fs.h
to 256.
from pam_e4crypt.
That can't happen if you simply create keys/policies for every ext4 filesystem on login. Or am I missing something? If not, then simply iterating over mtab and inserting a key generatied with every ext4 superblock-salt should do the trick.
Yes, it is possible to just create policies for all ext4 file systems present. However, you encrypt a directory with a specific policy, which in turn depends on a specific salt. As far as I know, it's impossible for a user to tell which policy was created from which FS/salt (when displaying them with the standard tools). If this were the case, then the problem could obviously be solved quite easily. I presume the e4rcypt add_key
variant with a path does the right thing, but that's not always what a user wants, e.g. when setting up multiple directories or just setting up any directories after login.
So, the problem isn't necessarily our capability to create those policies, but the user's capability to choose the correct policy when setting up some directory.
I don't think so: pam_e4crypt currently uses EXT4_MAX_SALT_SIZE, which is defined, at least on my system, in /usr/include/ext2fs/ext2_fs.h to 256.
Huh. ok. I thought it was 16
. Maybe it changed at some point. I'll have to check (e.g. in which version) and then update the documentation accordingly. Thanks for the hint!
from pam_e4crypt.
Related Issues (20)
- Keys not flushed from cache after logout HOT 1
- [Idea] Add an option for system-wide user specific salt HOT 6
- systemd --user instance doesn't inherit user's session keyring HOT 6
- Adhere to XDG spec HOT 2
- [info] fscrypt by google HOT 1
- Implement password management function HOT 5
- Packaged for distros HOT 1
- Add ext2fs package to cmake dependencies
- Userspace usage HOT 1
- Salt handling does not match `e4crypt add_key` HOT 1
- PAM failed: Cannot make/remove an entry for the specified session HOT 3
- Make a man page
- nice work HOT 1
- Mention cron problems in documentation HOT 1
- Is the 16-byte salt length required ? HOT 2
- Failure to transport keys from auth to session stage with pam-1.4.0
- sshd support HOT 6
- Changing LIBDIR to /usr/lib HOT 2
- pam_e4crypt: Failed to retrieve key list! HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pam_e4crypt.