Subject: How kauth can make meaningful decisions about passthru ioctls
To: None <email@example.com, firstname.lastname@example.org>
From: Thor Lancelot Simon <email@example.com>
Date: 11/27/2006 19:24:47
At present, amrctl doesn't work on systems at securelevel 1, although
the device driver can easily see that everything it's doing is safe:
it does three successive "IO command" ioctls on the amr device node,
but all those commands actually do is read configuration and status.
Unfortunately, the only correct thing for the driver to do, given our
current kauth support for passthru ioctls, is to ask the secmodel
whether it can do a "passthru" request or not. If the secmodel is to
respond in any safe way that is not simply "no" then it (the secmodel!)
must itself parse the device-specific command structure, which seems
like a poor idea: we will be unable to do many useful things without
embedding code that knows about device internals in the default secmodel.
One dreadful workaround would be to have the driver lie about what the
request is, and not ask the passthru kauth question if it believes the
request is "safe". I think this is not something we should do.
I think the right solution is to add more information to the passthru
question, so that the listener can distinguish diferent kinds of
requests without parsing them if it does not know how. This leaves,
by default, the code that knows how the device commands work in the
device driver, which is where it belongs. I propose that we
distinguish passthru commands by their worst possible consequences
(device drivers that cannot parse a given passthru command should
treat it as the most damaging command possible) into (at least) these
types: READ, WRITE, READCONF, WRITECONF where the latter two indicate
commands that can read (or write) device configuration/metadata rather
than data stored on the device or in host memory. I am not sure that
WRITECONF really needs to be separated from WRITE but I am sure that
READCONF does, in order to accurately describe the MegaRAID command
set and the security implications of using particular commands.
I am proposing WRITECONF pretty much for orthagonality.
These could also be bits in a word, for more flexibility in describing
commands. I'm not sure if this is better, but it would make determining
what the "worst possible" is much easier!