Score:-2

security risk? why ubuntu apply strange permissions in /boot/initrd* and /boot/vmlinuz*?

mx flag

the initrd.img are all 644, the vmlinuz in another hand is 600. This is reversed on many other distros if not all. I think other distros actually do it correctly. the content in vlinuz is all public available there is no secrets in there. However, the initrd can contain all sorts of customized settings which can expose attack surface when other instead of root can read its content. Moreover, it is a trends that people will include luks key in initrd when they do full disk encryption. Thus it is absolutely no! no! to set the initrd globally readable.

What is the reason behind this design? Why ubuntu need the initrd.img to be globally readable? Is there any functionality depends on this?

I hope experienced user can tell me how to make the initrd.img permanently 600 in ubuntu. Since these files are automatically generated during kernel updates. Maybe add some script in /etc/kernel/postinst.d/ ?

mx flag
so I get -1 for no reason ... because this question is too harsh for someone?
Terrance avatar
id flag
I didn't give you a downvote, but from reading your question you didn't ask a specific thing and instead are trying to do a discussion. See: https://askubuntu.com/help/how-to-ask I can tell you though that from using multiple Linux distros over the years, messing with the /boot file permissions can render your system not bootable.
cn flag
@Wang you are not asking a question we can answer. You need to ask the maintainer for a "What" and "Why". The better action would be to file a bugreport.
andrew.46 avatar
in flag
FWIW I see Slackware with initrd.gz as 0644 and kernel also as 0644, both owned by root. I am a little curious about the other distros you have looked at?
Score:3
cn flag

I see a difference between 20.04 and 22.04 which I have both installed on my machine. In 20.04 I see the behaviour you describe in your question while in 22.04 the initrd.img* files have 600 permissions.

Stumbling about this bug I checked the files in /etc/initramfs-tools and found the relevant file which exists in 22.04 but not in 20.04:

~$ sudo cat /etc/initramfs-tools/conf.d/calamares-safe-initramfs.conf 
[sudo] password for mook: 
UMASK=0077
~$ ls -l /etc/initramfs-tools/conf.d/calamares-safe-initramfs.conf 
-rw------- 1 root root 11 Apr 25 02:53 /etc/initramfs-tools/conf.d/calamares-safe-initramfs.conf

So I think, this is the file you need to add to get safe permissions for your initrd.img* files.

This will, of course not affect already existing initramfs images, use chmod to change their permissions to 600.

co flag
Note that Calamares isn't used on all Ubuntu flavors. (In fact, I think only Lubuntu uses Calamares.)
mook765 avatar
cn flag
@sarnold that might be true, but it should solve the problem regardless of the fact if the flavour of Ubuntu uses calamares or not.
Score:0
co flag

The kernel and symbols files are installed with permissions 0600 so exploits cannot read these files to learn what addresses or offsets to use in attacks. It's far from foolproof, since an attacker can download all the kernel packages ahead of time and build the necessary offset tables themselves, but it is additional work.

It might make sense to change the default initramfs permissions as described in @mook765's answer. If you feel strongly about it, please file a bug report. The help.ubuntu.com article on full disk encryption includes this step alongside the advice on how to embed keys into the initramfs.

The defaults should be safe for users that do not embed key material for other filesystems into their initramfs. (I believe this is a very rare configuration.)

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.