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] [day] [month] [year] [list]

Message-ID: <20111109161459.GD2557@kroah.com>
Date:	Wed, 9 Nov 2011 08:14:59 -0800
From:	Greg KH <greg@...ah.com>
To:	Ted Ts'o <tytso@....edu>, 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 Tue, Nov 08, 2011 at 03:07:35PM -0500, Ted Ts'o wrote:
> 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.

What other Unix systems actually implement revoke() in this manner?  I
looked at the BSDs a while ago, and they only do revoke() on a tty
character device node.

So are there other examples of someone actually implementing this in a
manner that works and is usable?  If so, pointers would be greatly
appreciated, as well as the userspace side that takes advantage of such
a system call.

> 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.  

That can be implemented today without the need for the userspace
revoke() call to be added, right?  Just propagate around the device
disconnect message that the disk controller driver already knows about.

thanks,

greg k-h
--
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/