* Matthew J. Fanto (mattjf@private) wrote:
>
> I've been speaking to Chris Wright about read-only /dev/kmem in an LSM.
> Current solutions (grsecurity for example) just return -EPERM inside
> drivers/char/mem.c::open_port(). We had a discussion about the nature of
> CAP_SYS_RAWIO, and have come to a few conclusions. Replacing calls to
> capable(CAP_SYS_RAWIO) would be problematic because we wouldn't know the
> context of the call to offer fine grained control. The only solutions we
> have come up with is either controlling /dev/kmem access through
> inode_permissions() or by adding a new hook that open_port() can call.
> The problem I see with inode_permissions() is the overhead of checking
> to see if it's /dev/kmem on every inode access. Would a new hook for
> open_port() be accepted? Is anyone aware of any other solution? Thanks.
My general feeling on new hooks at this point is that they require
some user and fill a clearly needed gap -- meaning this can't be done
another way and has some generality. So, open_port() is very specific
to just /dev/{kmem,mem,port}. Given that these exist as files in the
filesystem, the typical fs access control is perhaps the most flexible
way of achieving this (via, chmod, acl, or using smth. like
inode_permission hook).
Current RAWIO users are sort of all over the place, and finding a
conistent method to convert those users to is painful. We've tried to
keep our changes closer to core kernel and out of drivers where
possible.
So, at this point, I'm yet to be convinced ;-)
thanks
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
This archive was generated by hypermail 2b30 : Mon Mar 01 2004 - 18:09:43 PST