Date: Fri, 20 Oct 2017 21:25:03 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 223138] null(4) has DIOCSKERNELDUMP ioctl Message-ID: <bug-223138-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223138 Bug ID: 223138 Summary: null(4) has DIOCSKERNELDUMP ioctl Product: Base System Version: 11.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: freebsd-bugs@maxsi.org The /dev/null device unusually has a DIOCSKERNELDUMP ioctl that exists on no other operating system. This ioctl controls kernel crash dumping. What is t= his feature doing in this very unexpected place? I haven't checked but I assume= the ioctl requires administrative privileges to use but /dev/null is a strange = home for it. I don't believe this has any security implications. It just unnecessarily expose attack surface since /dev/null objects can commonly be given to sandboxed environments and is generally considered a certainly ben= ign object. DIOCSKERNELDUMP is not documented in null(4) but documented in dumpon(8). At the very least it should be documented in null(4). I would advocate for exposing the feature through a new kernel interface for this purpose (or another better suited home) rather than null(4), and then removing (perhaps in time) the feature from null(4). --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-223138-8>