linux-kernel - Re: [kernel-hardening] Re: [PATCH] proc: restrict access to /proc/interrupts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 8 Nov 2011 15:07:35 -0500
From:	Ted Ts'o <tytso@....edu>
To:	Greg KH <greg@...ah.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Vasiliy Kulikov <segoon@...nwall.com>,
	Eric Paris <eparis@...isplace.org>,
	kernel-hardening@...ts.openwall.com, Valdis.Kletnieks@...edu,
	linux-kernel@...r.kernel.org,
	Alexey Dobriyan <adobriyan@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-security-module@...r.kernel.org
Subject: Re: [kernel-hardening] Re: [PATCH] proc: restrict access to
 /proc/interrupts

On Mon, Nov 07, 2011 at 03:45:46PM -0800, Greg KH wrote:
> > As I mentioned at the kernel summit, I'd like revoke along with a
> > formal notification from block devices that get ejected to the file
> > system layer, and the file system should be able to call a VFS library
> > function which revokes all open file descriptor on the ejected block
> > device.  It would result in much cleaner handling at the file system
> > level when a USB storage device gets pulled.
> 
> So you want revoke() on a block device to do what?  The same thing as
> disconnecting it from the hardware level?

No, what I meant is that a disconnect at the hardware level should
lead to notification to the file system via a call to struct super
operations function.  And then the file system can use that callback
(call it super->s_ops->device_ejected) to call revoke on all of the
open files on the file system.

If we were to implement a revoke(2) system call (as opposed to just
VFS functionality callable from kernel code), it should probably do
what revoke(2) does on other Unix systems:

     The revoke() system call invalidates all current open file
     descriptors in the system for the file named by path.  Subsequent
     operations on any such descriptors fail, with the exceptions that
     a read() from a character device file which has been revoked
     returns a count of zero (end of file), and a close() system call
     will succeed.  If the file is a special file for a device which
     is open, the device close function is called as if all open
     references to the file had been closed.

     Access to a file may be revoked only by its owner or the super
     user.  The revoke() system call is currently supported only for
     block and character special device files.  It is normally used to
     prepare a terminal device for a new login session, preventing any
     access by a previous user of the terminal.

The revoke functionality I was talking about is a way to disconnect a
file descriptor from the mounted file system, since when the device
that backed it has disappeared, the file system should disappear as
well.  What should be left are file descriptors that return an error
when read or written, and which are administratively managed by the
VFS layer, with all of the file system's refcounts appropriate
decremented, such that if it were loaded as a module, the fs module
could be safely unloaded.  

      	 					- Ted

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/