From owner-freebsd-stable@FreeBSD.ORG Wed Jul 12 12:47:44 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8325B16A4E5 for ; Wed, 12 Jul 2006 12:47:44 +0000 (UTC) (envelope-from akosiaris@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3A7843D58 for ; Wed, 12 Jul 2006 12:47:42 +0000 (GMT) (envelope-from akosiaris@gmail.com) Received: by nz-out-0102.google.com with SMTP id f1so111457nzc for ; Wed, 12 Jul 2006 05:47:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=U8mwIuAaas4xgszn86ymCHLwE8Td763iSkwTATaGWE+6+zq9g37QPR3WsTS0Oi0GoguRLURnK0WpC4uP7W9Cj6EAKWcGZYyFBknEZlAwrieKI0G8I3KKlB0z8orE5eYMFK03l/GdzSEA3FnJtSEHvVPqh5qtbJAdObO2rNQY2JE= Received: by 10.36.67.7 with SMTP id p7mr812271nza; Wed, 12 Jul 2006 05:47:42 -0700 (PDT) Received: by 10.36.55.20 with HTTP; Wed, 12 Jul 2006 05:47:41 -0700 (PDT) Message-ID: Date: Wed, 12 Jul 2006 15:47:41 +0300 From: "Alexandros Kosiaris" To: freebsd-stable@freebsd.org, freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: Securelevels and /dev/io documentation inconsistency X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 12:47:44 -0000 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