automotive-grade-linux / docs-agl

AGL Technical Documentation
Apache License 2.0
54 stars 50 forks source link

Problems in the security blueprint #112

Open elimordechai opened 6 years ago

elimordechai commented 6 years ago

1) Library linking Linking everything statically doesn't change anything wrt security as binaries will live under same user:group as libraries and setuid executables ignore LD_PRELOAD/LD_LIBRARY_PATH. It also increases RSS footprint and creates problems with upgrading.

2) Disable swap Enabling swap at runtime require CAP_SYS_ADMIN. Swap block device is usually under root:disk which is already privileged enough access. Another thing is that Linux never swaps kernel pages. Swap should be disabled or encrypted if offline attacks are a problem.

3)"Kernel debug symbols" aka disable CONFIG_DEBUG_INFO kernel debuginfo is only produced during kernel build and is stripped from final "vmlinux" file /boot/vmlinuz-* doesn't contain debuginfo and "vmlinux" is unbootable kernel image.

So emphasis of the point should be on the suggestion that kernel source, kernel .config, and kernel image should not be publicly available and that kernel and modules should be stripped before shipping.

At least CONFIG_DEBUG_INFO_REDUCED should be always ebnabled for developers to convert addresses in oops messages to line numbers which is very useful.

4) disabled CONFIG_DEBUG_KERNEL blanket disable is wrong thing to do as it contains CONFIG_DEBUG_LIST option for finding list corruptions. RHEL ships kernel with CONFIG_DEBUG_LIST enabled as it doesn't have much overhead.

Other cheap options may appear in future.

5) disable CONFIG_PACKET_DIAG, CONFIG_UNIX_DIAG rationale sounds scary but code is not

In particular CONFIG_UNIX_DIAG exports ->sun_path of a unix socket (which hardly can be considered a secret) st_dev:st_ino of a socket inode (available through /proc) peer st_ino (available through /proc) send/recv queue len socket buffer lengths, drop count shutdown state

while queue lengths and socket buffer lengths may be helpful do triggering bugs, there are no kernel data structures exposed

PACKET_DIAG has the same nature

Both interfaces were developed because parsing /proc/net/unix is slow for big number of sockets (and is generally slower than binary netlink interface).

It should be disabled because userspace shipped doesn't use it.

==================

small corrections for some points: 6) kexec kexec can indeed load arbitrary kernels but signing of new kernel can be enforced like it is can be enforced for new modules

7) firmware autoloader it doesn't strictly need to be setuid there is an option of shipping firmware builtin into kernel without initrd/filesystem

8) module signing suggest a) disable kernel modules altogether, b) load necessary modules at startup, disable module loading with kernel.modules_disabled=1 c) enforce module signing

9) -D_FORTIFY_SOURCE kernel has sister option CONFIG_FORTIFY_SOURCE. Kernel doesn't do many string operations so strcpy bugs aren't as problematic as they were in userspace.

==================

Banks and financial institutions have this "know your customer" rule. In its spirit I propose "know your .config" rule:

for every CONFIG...=y and CONFIG...=m line know which hardware or userspace program uses the functionality. If you don't know what it is used for it should probably be disabled.

This is especially true for embedded developers which run more constrained hardware and software configurations than general purpose distributions.

options which can be put under this rule -sysctl(2) -uselib(2) BPF JIT (used only for high performance configurations) -USB, -PCMCIA /dev/kmem /dev/mem /proc/kcore process_vm_readv(2), process_vm_writev(2) KGDB sysrq (debugging interface) binfmt_misc kprobes (require module loading capability anyway) ftrace profiling coredump /proc/config.gz nfs

If you don't need it, disable it which is sound advice. It will also make kernel smaller which is always good.

mudcam commented 6 years ago

Hello, here is the link to the pull request: https://github.com/automotive-grade-linux/docs-agl/pull/113 I've integrated parts one, two and six through nine.

Concerning the last part, it's a good suggestion, would you have some doc on the subject ? I've not integrated points relating to the development environment. It is best to show in this document what AGL would look like in production.

Thank you for your comments. Nieutin Vincent.

sebd71 commented 6 years ago

Eli, any chance to answer Vincent's questions ? Thanks.

kooltux commented 6 years ago

Ping