mount --bind accounting
Something entirely different.
Last year I added the comment
/* No capabilities? What if users do thousands of these? */
in super.c for "mount --bind".
Now that I do some polishing there I noticed the comment again.
Each bind does an alloc_vfsmnt() and hence takes some kernel memory. Any user can therefore take all kernel memory, until
kmalloc(sizeof(struct vfsmount), GFP_KERNEL)
fails. Bad security.
I suppose something needs to be done about that.
Invent an arbitrary limit
#define MAX_NUMBER_OF_USER_BINDS 666
and refuse the "mount --bind" when inspection of the mnt_owner fields of the entries in the vfsmntlist shows that this user already has too many mounts?
Andries
Quoted 4 lines · On Sun, 3 Jun 2001 [email protected] wrote:
Something entirely different.
Last year I added the comment
/* No capabilities? What if users do thousands of these? */
Quoted 8 lines
in
super.cfor "mount --bind".
Now that I do some polishing there I noticed the comment again.Each bind does an
alloc_vfsmnt()and hence takes some kernel memory. Any user can therefore take all kernel memory, until
kmalloc(sizeof(struct vfsmount), GFP_KERNEL)
fails. Bad security.
I suppose something needs to be done about that.
Like looking at mount_is_safe(), maybe?
Hi,
Quoted 4 lines · On Sun, Jun 03, 2001 at 10:38:29PM +0200, [email protected] wrote:
Each bind does an
alloc_vfsmnt()and hence takes some kernel memory. Any user can therefore take all kernel memory, until
kmalloc(sizeof(struct vfsmount), GFP_KERNEL)
fails. Bad security.
Until we can account properly for basic things like page tables, the small kmallocs for things like vfsmount and file structs will be negligible in comparison.
Fortunately we used to have at least skeleton patches for a framework in which to do this. Whatever happened to beancounter, anyway? Is somebody maintaining that at all these days?
Cheers,
Stephen