[Compliance] Ensure the system.map is readable only by root

[xumia]

Why I did it

[Security] Ensure the system.map is readable only by root

It is based on the scan result: https://www.open-scap.org/security-policies/scap-security-guide/

Work item tracking

• Microsoft ADO (number only): 17611529

How I did it

The current permission is 0644, need to change to 0600.

How to verify it

Which release branch to backport (provide reason below if selected)

• 201811
• 201911
• 202006
• 202012
• 202106
• 202111
• 202205
• 202211
• 202305

Tested branch (Please provide the tested image version)

Description for the changelog

Link to config_db schema for YANG module changes

A picture of a cute animal (not mandatory but encouraged)

[saiarcot895]

The System.map file in Bullseye-based images is not the actual System.map file. Do we still need to have it be readable by root only?

admin@str2-7215-acs-1:~$ cat /boot/System.map-5.10.0-18-2-armmp
ffffffffffffffff B The real System.map is in the linux-image-<version>-dbg package

[xumia]

The System.map file in Bullseye-based images is not the actual System.map file. Do we still need to have it be readable by root only?

admin@str2-7215-acs-1:~$ cat /boot/System.map-5.10.0-18-2-armmp
ffffffffffffffff B The real System.map is in the linux-image-<version>-dbg package

@saiarcot895 , the scan should only check the file name, no care the file content. Do you know who will use it? Is it any impact changing to root readonly?

root@sonic:/boot# dpkg -L linux-image-5.10.0-18-2-amd64-unsigned 
/.
/boot
/boot/System.map-5.10.0-18-2-amd64
/boot/config-5.10.0-18-2-amd64
/boot/vmlinuz-5.10.0-18-2-amd64

/boot/System.map-5.10.0-18-2-amd64 is no used? can we remove it?

[saiarcot895]

I don't think we have a process using this file, but it might be there for consistency/expectation purposes. I'm fine with making this root readonly, but I'll also work on a change on the sonic-linux-kernel side to make sure the file gets packaged as root readonly, so that it won't need to be manually changed here.

[xumia]

I don't think we have a process using this file, but it might be there for consistency/expectation purposes. I'm fine with making this root readonly, but I'll also work on a change on the sonic-linux-kernel side to make sure the file gets packaged as root readonly, so that it won't need to be manually changed here.

Looks like the debian/ folder is not in the submodule sonic-linux-kernel, but copied from the storage account, https://github.com/sonic-net/sonic-linux-kernel/blob/d070cae8e92ae3cd9798546e27d796a71fd7e914/Makefile#L59

SOURCE_FILE_BASE_URL="https://sonicstorage.blob.core.windows.net/debian-security/pool/updates/main/l/linux"

[saiarcot895]

Yes, but we have patches that modify files in the debian/ folder already, so this would be another patch.

[jarias-lfx]

/easycla

[xumia]

Yes, but we have patches that modify files in the debian/ folder already, so this would be another patch.

@saiarcot895 , do you suggest adding the patch in https://github.com/sonic-net/sonic-linux-kernel/tree/master/patch, right?
I created a PR: sonic-net/sonic-linux-kernel#329, if we can merge it in the sonic-linux-kernel, this PR can be closed. Please help review the sonic-linux-kernel PR as well, thanks.