User: Password:
|
|
Subscribe / Log in / New account

Security modules and ioctl()

Security modules and ioctl()

Posted Feb 17, 2011 8:41 UTC (Thu) by michaeljt (subscriber, #39183)
Parent article: Security modules and ioctl()

> The obvious objections were raised at that time: changing every driver in the system would be a pain, ioctl() implementations are already messy enough as it is, the tables would not be maintained as the driver changed, and so on.

Making ioctls more painful to maintain might encourage people to add less new ones though, which would probably make many people happy.


(Log in to post comments)

Security modules and ioctl()

Posted Feb 17, 2011 13:31 UTC (Thu) by nix (subscriber, #2304) [Link]

Well, one possible fix is to rip the ioctl() and unlocked_ioctl() operations out of file_operations completely, turning them into a mandatory lookup into a (per-driver? per-filesystem?) map from ioctl request to (read_required, write_required, function to call to implement this operation).

Upside: makes it impossible to define a new ioctl() request without specifying whether it is a read or write op. Downside: this is... unlikely to be a nondisruptive change, and it's only really for the benefit of LSMs (since the read/write permission bits on devices supporting ioctl() are not used to validate this sort of thing, though they should be, but that would probably break too much of userspace). Which is probably why nobody's done it already.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds