On Mon, Jan 20, 2020 at 04:41:42PM -0700, Theo de Raadt wrote:
> The test is:
>
> switch (minor(dev)) {
> case 0:
> case 1:
> if (securelevel <= 0 || allowkmem)
> break;
> return (EPERM);
>
> Maybe
> /dev/mem and /dev/kmem cannot be opened (unless permitted by sysctl(8)
> kern.allowkmem)
>
> Your text about read-only must be incorrect. That is decided by the
> permission of the nodes in the filesystem, not by securelevel or
> kern.allowkmem.... the idea is you can't open it, so you can't read/write/map.
Behaviour on my system tells a different story.
I'm root, filesystem is read-write and nodes in filesystem are writable:
# id -u
0
# df /dev
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/sd1a 1032526 160470 820430 16% /
# mount | grep sd1a
/dev/sd1a on / type ffs (local)
# ls -l /dev/mem
crw-r----- 1 root kmem 2, 0 Jan 19 21:53 /dev/mem
Sysctl:
# sysctl kern.securelevel kern.allowkmem
kern.securelevel=1
kern.allowkmem=1
Test program below tries to open the node read-only first, then
read-write:
# cat mem.c
#include <err.h>
#include <fcntl.h>
#include <unistd.h>
int main(int argc, char **argv) {
int fd;
if ((fd = open("/dev/mem", O_RDONLY)) == -1)
err(1, "open read-only");
close(fd);
warnx("open /dev/mem read-only");
if ((fd = open("/dev/mem", O_RDWR)) == -1)
err(1, "open read-write");
close(fd);
warnx("opened /dev/mem read-write");
return 0;
}
# cc mem.c
# a.out
a.out: open /dev/mem read-only
a.out: open read-write: Operation not permitted
This shows that mem(4) can be opened at "Secure mode" even though
securelevel(7) says it cannot.
