freebsd stable - Jul 2006 - Securelevels and /dev/io documentation inconsistency

Hello,

I believe i have stumbled upon a documentation inconsistency
concerning securelevels and usage of /dev/io
>From init(8) manpage
  1     Secure mode - the system immutable and system append-only flags may
           not be turned off; disks for mounted file systems, /dev/mem,
           /dev/kmem and /dev/io (if your platform has it) may not be opened
           for writing; kernel modules (see kld(4)) may not be loaded or
           unloaded.

Note the "may not be opened for writing". It is correct for /dev/mem
and /dev/kmem but incorrect for /dev/io as the following experiment
shows:

3:40pm  ~ # sysctl kern.securelevel
kern.securelevel: 1
root@mybox
3:40pm  ~ # head /dev/io
head: /dev/io: Operation not permitted
root@mybox
3:40pm  ~ #

Now the source code in /usr/src/sys/i386/i386/io.c just checks if
securelevel is greater that 0 when opening the device and return
accordingly.

However from io(4)

Note that even read-only access will grant the full I/O privileges.

Which means that changing the code to check if the device is opened
O_RDONLY and then allowing access would be a mistake cancelling the
idea of blocking access to the device through usage of the
securelevel.

I am correct about the above ?
Does the documentation need a correction in that place?

Thanks,

alex

On 2006-07-12 15:47, Alexandros Kosiaris <akosiaris@gmail.com>
wrote:
> Hello,
>
> I believe i have stumbled upon a documentation inconsistency
> concerning securelevels and usage of /dev/io
>
> >From init(8) manpage
>
>  1     Secure mode - the system immutable and system append-only flags may
>           not be turned off; disks for mounted file systems, /dev/mem,
>           /dev/kmem and /dev/io (if your platform has it) may not be opened
>           for writing; kernel modules (see kld(4)) may not be loaded or
>           unloaded.
>
> Note the "may not be opened for writing". It is correct for
/dev/mem
> and /dev/kmem but incorrect for /dev/io as the following experiment
> shows:
>
> 3:40pm  ~ # sysctl kern.securelevel
> kern.securelevel: 1
> root@mybox
> 3:40pm  ~ # head /dev/io
> head: /dev/io: Operation not permitted
> root@mybox
> 3:40pm  ~ #
>
> Now the source code in /usr/src/sys/i386/i386/io.c just checks if
> securelevel is greater that 0 when opening the device and return
> accordingly.
>
> However from io(4)
>
> Note that even read-only access will grant the full I/O privileges.
>
> Which means that changing the code to check if the device is opened
> O_RDONLY and then allowing access would be a mistake cancelling the
> idea of blocking access to the device through usage of the
> securelevel.
>
> I am correct about the above ?
> Does the documentation need a correction in that place?
It looks like it does.  Would something like this be satisfactory?

    1		Secure mode - the system immutable and system
		append-only flags may not be turned off; disks for
		mounted file systems, /dev/mem and /dev/kmem may not be
		opened for writing and /dev/io (if your platform has it)
		may not be opened at all; kernel modules (see kld(4))
		may not be loaded or unloaded.

Regards,
Giorgos

> It looks like it does.  Would something like this be satisfactory?
>
>     1           Secure mode - the system immutable and system
>                 append-only flags may not be turned off; disks for
>                 mounted file systems, /dev/mem and /dev/kmem may not be
>                 opened for writing and /dev/io (if your platform has it)
>                 may not be opened at all; kernel modules (see kld(4))
>                 may not be loaded or unloaded.
>
> Regards,
> Giorgos
>
Yes it would be. Thank you.