headers
Thor Lancelot Simon | 7 Apr 2007 20:51

Re: port bio(4) and bioctl(8) from openbsd ?

On Sat, Apr 07, 2007 at 06:00:14PM +0200, Manuel Bouyer wrote:
> 
> I want this for mfi(4), for which I have no alternatives to get RAID status
> (if a drive fail you don't know, unless you go in front of the box and look
> at the LEDs). I will also add support to amr(4) as I have the hardware
> for this.

Anywhere this can _change_ RAID set or controller state, it needs very
careful attention to not break the security model.  Of course OpenBSD
didn't bother to deal with this because they're all about security.

Elad added the necessary hooks for this for this to kauth and I was
going to add an appropriate implementation for amr's management interface
(basically, you have to parse the command being sent by the user to the
controller firmware to decide if it's permissible or not) but unfortunately
I've been tremendously distracted.  But if we're going to rip out the old
device-specific management interfaces that let users bang directly on the
device firmware, and filter these accesses through bio instead, it's an
ideal opportunity to get the security stuff right.

Thor
Permalink | Reply | 0 comments |
headers
Manuel Bouyer | 7 Apr 2007 21:01

Re: port bio(4) and bioctl(8) from openbsd ?

On Sat, Apr 07, 2007 at 02:51:44PM -0400, Thor Lancelot Simon wrote:
> On Sat, Apr 07, 2007 at 06:00:14PM +0200, Manuel Bouyer wrote:
> > 
> > I want this for mfi(4), for which I have no alternatives to get RAID status
> > (if a drive fail you don't know, unless you go in front of the box and look
> > at the LEDs). I will also add support to amr(4) as I have the hardware
> > for this.
> 
> Anywhere this can _change_ RAID set or controller state, it needs very
> careful attention to not break the security model.  Of course OpenBSD
> didn't bother to deal with this because they're all about security.
> 
> Elad added the necessary hooks for this for this to kauth and I was
> going to add an appropriate implementation for amr's management interface
> (basically, you have to parse the command being sent by the user to the
> controller firmware to decide if it's permissible or not) but unfortunately
> I've been tremendously distracted.  But if we're going to rip out the old
> device-specific management interfaces that let users bang directly on the
> device firmware, and filter these accesses through bio instead, it's an
> ideal opportunity to get the security stuff right.

Sure. Any pointer to examples, or code/documentation ?
I guess this should be done in the device scope ?

--

-- 
Manuel Bouyer <bouyer <at> antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--
(Continue reading)

Permalink | Reply | 0 comments |

Gmane