From seth@psychotic.aberrant.org  Mon Dec 10 10:06:32 2001
Return-Path: <seth@psychotic.aberrant.org>
Received: from psychotic.aberrant.org (psychotic.aberrant.org [66.92.161.103])
	by hub.freebsd.org (Postfix) with ESMTP id 6584D37B416
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 10 Dec 2001 10:06:31 -0800 (PST)
Received: by psychotic.aberrant.org (Postfix, from userid 1000)
	id 6711472501; Mon, 10 Dec 2001 13:06:15 -0500 (EST)
Message-Id: <20011210180615.6711472501@psychotic.aberrant.org>
Date: Mon, 10 Dec 2001 13:06:15 -0500 (EST)
From: seth@psychotic.aberrant.org
Reply-To: seth@psychotic.aberrant.org
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: pciconf -l opens /dev/pci for O_RDWR
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         32677
>Category:       kern
>Synopsis:       pciconf -l opens /dev/pci for read/write when should be readonly
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Dec 10 10:10:01 PST 2001
>Closed-Date:    Sun Feb 08 04:51:42 PST 2004
>Last-Modified:  Sun Feb 08 04:51:42 PST 2004
>Originator:     Seth
>Release:        FreeBSD 4.3-STABLE i386
>Organization:
>Environment:
System: FreeBSD psychotic.aberrant.org 4.3-STABLE FreeBSD 4.3-STABLE #0: Tue Nov 13 13:13:03 EST 2001 seth@psychotic.aberrant.org:/usr/src/sys/compile/KERNEL-F i386

>Description:
pciconf -l tries to open /dev/pci O_RDWR even though it shouldn't be writing
anything.  This causes it to fail under either of the following circum-
stances:
  1.  user is not root
  2.  securelevel > 0

According to the manpage for pciconf,

     The -l option is the only one available to non-root users.

According to the init manpage,

     1     Secure mode - the system immutable and system append-only flags may
           not be turned off; disks for mounted filesystems, /dev/mem, and
           /dev/kmem may not be opened for writing; kernel modules (see
           kld(4)) may not be loaded or unloaded.

>How-To-Repeat:
  pciconf -l as a normal (non-root) user, or 
  truss pciconf -l as root in securelevel 1:

open("/dev/pci",2,00)                            ERR#1 'Operation not permitted'
pciconf: write(2,0xbfbfcad8,9)                           = 9 (0x9)

>Fix:

Check arguments to pciconf.  If -l, open O_RDONLY.


>Release-Note:
>Audit-Trail:

From: Brooks Davis <brooks@one-eyed-alien.net>
To: seth@psychotic.aberrant.org
Cc: FreeBSD-gnats-submit@FreeBSD.ORG, msmith@FreeBSD.ORG
Subject: Re: kern/32677: pciconf -l opens /dev/pci for O_RDWR
Date: Mon, 10 Dec 2001 12:00:05 -0800

 On Mon, Dec 10, 2001 at 01:06:15PM -0500, seth@psychotic.aberrant.org wrote:
 > Check arguments to pciconf.  If -l, open O_RDONLY.
 
 This doesn't actually work.  The current ioctl access controls require
 that you have the device opened for write in all cases.  This is a rather
 odd check, but it's the case.  My recollection of the last conversation
 about this on the lists is that on some configurations the ability to
 read pci state is the ability to crash the system so it is restricted.
 It seems PCIOCGETCONF and PCIOCREAD should probalby be allowed if the
 user can read the device and the device nodes should be fixed to be
 unreadable to non-root users, but there may be some reason for the
 current configuration that I don't know about.  I've CC'd Mike Smith for
 his opinion on this.
 
 -- Brooks

From: Mike Smith <msmith@freebsd.org>
To: Brooks Davis <brooks@one-eyed-alien.net>
Cc: seth@psychotic.aberrant.org, FreeBSD-gnats-submit@FreeBSD.ORG,
	msmith@FreeBSD.ORG, msmith@mass.dis.org
Subject: Re: kern/32677: pciconf -l opens /dev/pci for O_RDWR 
Date: Mon, 10 Dec 2001 14:35:23 -0800

 > On Mon, Dec 10, 2001 at 01:06:15PM -0500, seth@psychotic.aberrant.org wrote:
 > > Check arguments to pciconf.  If -l, open O_RDONLY.
 > 
 > This doesn't actually work.  The current ioctl access controls require
 > that you have the device opened for write in all cases.  This is a rather
 > odd check, but it's the case.  My recollection of the last conversation
 > about this on the lists is that on some configurations the ability to
 > read pci state is the ability to crash the system so it is restricted.
 > It seems PCIOCGETCONF and PCIOCREAD should probalby be allowed if the
 > user can read the device and the device nodes should be fixed to be
 > unreadable to non-root users, but there may be some reason for the
 > current configuration that I don't know about.  I've CC'd Mike Smith for
 > his opinion on this.
 
 The problem with reading is that on some Alpha systems, you can cause
 a machine check with an unaligned read.  The correct fix would be to
 reject these reads at a suitable level in the Alpha PCI code, but a
 bandaid was implemented instead.
 
 A correct fix for this would be to correct the Alpha PCI code to check, and
 then check the open mode in a more logical fashion.

From: Seth <seth@bromberger.com>
To: Mike Smith <msmith@freebsd.org>
Cc: Brooks Davis <brooks@one-eyed-alien.net>,
	FreeBSD-gnats-submit@FreeBSD.ORG, msmith@mass.dis.org
Subject: Re: kern/32677: pciconf -l opens /dev/pci for O_RDWR
Date: Tue, 11 Dec 2001 07:13:07 -0500

 Mike/Brooks,
 
 Thanks for the update & explanation.  I guess this means that stock pciconf
 will remain unusable on systems where securelevel > 0 until the Alpha
 code can be tweaked?
 
 If I were to patch my own code to open O_RDONLY (I'm on Intel/AMD), do you
 anticipate that I would experience any problems such as you describe below?
 
 Thanks,
 
 Seth.
 
 On Mon, Dec 10, 2001 at 02:35:23PM -0800, Mike Smith wrote:
 > > On Mon, Dec 10, 2001 at 01:06:15PM -0500, seth@psychotic.aberrant.org wrote:
 > > > Check arguments to pciconf.  If -l, open O_RDONLY.
 > > 
 > > This doesn't actually work.  The current ioctl access controls require
 > > that you have the device opened for write in all cases.  This is a rather
 > > odd check, but it's the case.  My recollection of the last conversation
 > > about this on the lists is that on some configurations the ability to
 > > read pci state is the ability to crash the system so it is restricted.
 > > It seems PCIOCGETCONF and PCIOCREAD should probalby be allowed if the
 > > user can read the device and the device nodes should be fixed to be
 > > unreadable to non-root users, but there may be some reason for the
 > > current configuration that I don't know about.  I've CC'd Mike Smith for
 > > his opinion on this.
 > 
 > The problem with reading is that on some Alpha systems, you can cause
 > a machine check with an unaligned read.  The correct fix would be to
 > reject these reads at a suitable level in the Alpha PCI code, but a
 > bandaid was implemented instead.
 > 
 > A correct fix for this would be to correct the Alpha PCI code to check, and
 > then check the open mode in a more logical fashion.

From: Brooks Davis <brooks@one-eyed-alien.net>
To: Seth <seth@bromberger.com>
Cc: FreeBSD-gnats-submit@freebsd.org, msmith@freebsd.org
Subject: Re: kern/32677: pciconf -l opens /dev/pci for O_RDWR
Date: Tue, 11 Dec 2001 07:59:37 -0800

 On Tue, Dec 11, 2001 at 07:13:07AM -0500, Seth wrote:
 > Mike/Brooks,
 > 
 > Thanks for the update & explanation.  I guess this means that stock pciconf
 > will remain unusable on systems where securelevel > 0 until the Alpha
 > code can be tweaked?
 > 
 > If I were to patch my own code to open O_RDONLY (I'm on Intel/AMD), do you
 > anticipate that I would experience any problems such as you describe below?
 
 I tried it before looking at the kernel code and it actually doesn't work
 due to the way the kernel is configured.  You would need to do that (it's
 quite easy) and then modify pci_ioctl() at sys/pci/pci.c:752 moving the
 "if (!(flag & FWRITE))" check into PCIOCWRITE.
 
 -- Brooks
 
 -- 
 Any statement of the form "X is the one, true Y" is FALSE.
 PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4
State-Changed-From-To: open->closed 
State-Changed-By: das 
State-Changed-When: Sun Feb 8 04:50:40 PST 2004 
State-Changed-Why:  
It looks like this was fixed by rwatson in 
src/usr.sbin/pciconf/pciconf.c,v 1.20. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=32677 
>Unformatted:


