Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Race condition in changing permissions #1190

Closed
setharnold opened this issue Jul 2, 2019 · 5 comments
Closed

Race condition in changing permissions #1190

setharnold opened this issue Jul 2, 2019 · 5 comments

Comments

@setharnold
Copy link

setharnold commented Jul 2, 2019

Hello, please note that there's a race condition between the time when the key file is created and when the permissions are changed that it is probably visible to some or all users on the system.

check_target_env_call(["chmod",

The safe way to create a file with restricted permissions is to set the process umask(2) before creating the file. The shell built-in umask(1) command can do this.

Thanks

@tsimonq2
Copy link
Contributor

tsimonq2 commented Jul 2, 2019

@setharnold
Copy link
Author

Note that that's a separate issue, about the initramfs.

Thanks

@tsimonq2
Copy link
Contributor

tsimonq2 commented Jul 2, 2019

Separate issue filed: #1191

@teward
Copy link

teward commented Jul 2, 2019

This issue here has been assigned CVE ID of CVE-2019-13178 by MITRE.

adriaandegroot added a commit that referenced this issue Jul 4, 2019
adriaandegroot added a commit that referenced this issue Jul 4, 2019
 - This is a simple variation on the theme of things-that-call-a-
   initramfs-updater, so the code is mostly a copy of initramfs/
   module. I didn't even bother to strip out the configuration-
   handling (I figure it might be good for *something*) so now
   "" and "$uname" are valid kernel names as well.
 - Fixes security issue where the initramfs ends up readable
   by all, and that includes the cryptfile for LUKS.

SEE #1190
@adriaandegroot
Copy link
Contributor

The merge of issue-1190 branch has fixed this problem: before running dd, the umask is set to 077, and this does the right thing. The crypto key is written with permissions 0600. I have verified this across installs on lubuntu, neon, and chakra.

Leaving the issue open, though, until there is a release with the fix included.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants