Bug 32677
| Summary: | pciconf -l opens /dev/pci for read/write when should be readonly | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Seth <seth> |
| Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 4.3-STABLE | ||
| Hardware: | Any | ||
| OS: | Any | ||
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 > 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.
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.
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 It looks like this was fixed by rwatson in src/usr.sbin/pciconf/pciconf.c,v 1.20. |
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. Fix: Check arguments to pciconf. If -l, open O_RDONLY. 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)