Date: Tue, 24 Aug 1999 18:48:10 -0400 (EDT) From: Gardner <gardner@gromit.dhs.org> To: FreeBSD-gnats-submit@freebsd.org Subject: kern/13359: Read permission to /dev/io does not grant IO to non-root processes Message-ID: <199908242248.SAA83944@gromit.dhs.org>
index | next in thread | raw e-mail
>Number: 13359
>Category: kern
>Synopsis: Read permission to /dev/io does not grant IO to non-root processes
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Tue Aug 24 15:50:00 PDT 1999
>Closed-Date:
>Last-Modified:
>Originator: Gardner Buchanan
>Release: FreeBSD 3.1-RELEASE i386
>Organization:
>Environment:
3.2-RELEASE
>Description:
The manual page io(4) indicates that the entire access control to
port IO permission is handled by the file access permissions of
/dev/io. This is incorrect, as the code seems also to care about
the actual process credentials. Granting read permission to /dev/io
does not effectively grant IO priviledges to non-root processes.
>How-To-Repeat:
Running 3.2-RELEASE I encountered this, that I thought was weird:
gardner@bongo=> id
uid=300(gardner) gid=20(staff) groups=20(staff), 0(wheel)
gardner@bongo=> ls -l /dev/io
crw-rw---- 1 root wheel 2, 14 Jul 11 14:05 /dev/io
gardner@bongo=> cat /dev/io
cat: /dev/io: Operation not permitted
su-2.02# id
uid=0(root) gid=0(wheel) groups=0(wheel), 2(kmem), 3(sys),
4(tty), 5(operator), 20(staff), 31(guest)
su-2.02# cat /dev/io
cat: /dev/io: Device not configured
"Device not configured" is the expected result.
The manual page io(4) still tells me:
The entire access control is handled by the file access
permissions of /dev/io, so care should be taken in granting
rights for this device. Note that even read/only access will
grant the full I/O privileges.
Which isn't true. In fact the code in mem.c is checking my process
credentials as well:
case 14:
error = suser(p->p_ucred, &p->p_acflag);
if (error != 0)
return (error);
if (securelevel > 0)
return (EPERM);
curproc->p_md.md_regs->tf_eflags |= PSL_IOPL;
(I also think that reading /dev/io should give me EOF, not ENXIO)
>Fix:
Correct io(4) or remove the suser() check in mem.c
>Release-Note:
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199908242248.SAA83944>