Post by Rainer Weikusat Post by Scott Lurndal Post by Rainer Weikusat Post by Scott Lurndal Post by Rainer Weikusat
Something which just occured to me while coming up with a secure way a
setuid program can use to communicate something to the (unprivileged)
Due to "Modern !!1"-disease, a setuid program running on Linux cannot
safely use any file descriptors it might have inherited.
A setuid program must not trust any state it inherits, including
As explained elsewhere: Assuming UNIX permission semantics, it can
safely do things like "write output to stdout" because the file
descriptor can only refer to something the invoking process had
permission to use.
Although writing to a tun/tap file descriptor won't do anything;
one needs to use ioctl's first to setup the device.
"In order to use the driver a program has to open /dev/net/tun and issue a
corresponding ioctl() to register a network device with the kernel. A network
device will appear as tunXX or tapXX, depending on the options chosen. When
the program closes the file descriptor, the network device and all
corresponding routes will disappear."
Accidental property of the example. The concept is nevertheless flawed
(or "unsuitable for certain aspects of the environment it resides in").
It all returns to basic security principles. Don't trust anything
inherited in a setuid (or setcap) application.
Post by Rainer Weikusat
NB: Presumably, the people who implemented this are convinced that
"setuid is a broken concept, anyway" (aka "Does not exist on Windows").
The security experts who initially implemented capabilities (at SGI)
and who donated much of what is there today (along with NSA's selinux)
would disagree with your rationale. Clearly minimizing the
privilege granted to code is one of the key principles of good
This, of course, long predates Linux (and its implementation in various
unix in the 90's, eg. SVR4 ES/MP); as the HP-3000 security model in
the MPE operating system was based on a capabilities, and the VAX VMS
security model was also based on capabilities.
In both systems, applications could installed with extra capabilities
by the system manager (on the HP, someone with SM privilege). This,
of course, led to security issues for both operating systems (e.g.
the HP-3000 Basic interpreter was installed with "PH" (Process Handling
) capability which allowed code to manipulate process priorities,
queue assignments, etc. Since you could call SPL/3000 functions from
basic, that pretty much allowed anyone to use PH caps). On the VAX,
the debugger was installed with change mode to kernel capability. One
doesn't need a great imagination to see the dangers in that.
In both cases, the holes were easily closed by removing said (and
generally unnecessary) capability from the applications.
Post by Rainer Weikusat
Aside: After the network device has been created (and configured),
reading or writing to the file descriptor can be used to send or receive
datagrams/ ethernet frames from/ to the interface.
My current work project uses tap devices extensively.