linux-kernel - Re: r-o bind in nfsd

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]

Message-Id: <200803221120.ADB21850.SLtOJMFFOVOFQH@I-love.SAKURA.ne.jp>
Date:	Sat, 22 Mar 2008 11:20:03 +0900
From:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To:	miklos@...redi.hu, viro@...IV.linux.org.uk
Cc:	haveblue@...ibm.com, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, neilb@...e.de,
	akpm@...ux-foundation.org, hch@...radead.org,
	linux-security-module@...r.kernel.org, jmorris@...ei.org
Subject: Re: r-o bind in nfsd

Hello.

> As for the apparmor and friends...  I'm far past the point of trying to
> give them feedback, seeing how any such feedback is ignored, if not worse
> (the ugliness of some of the suggested kludges is bloody astonishing - e.g.
> some guy proposed to stuff a reference to vfsmount into task_struct, etc.)
TOMOYO is one of AppArmor's friends, and I am the guy who proposed to pass
a reference to vfsmount via task_struct as if that reference is passed via stack memory.

> > Because filesystem shouldn't _care_ where it is mounted.  Anything
> > vfsmount-dependent belongs to upper layers.  The same goes for passing
> > nameidata to fs methods, BTW - again, ->follow_link() is an obvious
> > legitimate exception.
> 
> Nobody wants to send vfsmounts to the filesystem.  But vfs_...() are
> still part of the "upper layer", not the filesystem, so I'm not
> convinced yet.  For example:
I'm not asking to pass the vfsmount parameter to individual filesystem's "vfs functions".
I'm asking to pass the vfsmount parameter to the "vfs *helper* functions".
So, filesytem will not care where it is mounted
even if the vfsmount is passed to "vfs *helper* functions".
The vfs helper functions are designed to aggregate common checks (permission checks,
inode_operations->foo existence checks etc.) to avoid scattering same code everywhere
in the kernel, didn't they?

> Assuming of course, that all valid users _do_ have the vfsmount
> available, which I think is true.  If you have a counterexample,
> please let us know.
At least, calls to vfs helper functions from userland code
_do_ have the vfsmount available because they are called immediately after the name resolution.

Calls to vfs helper functions from kernel code does not always have the vfsmount available,
but that's beyond what the LSM can do.
We must trust kernel code, because kernel code can bypass the LSM check
if the kernel code is malicious enough to directly call "vfs functions" instead of
calling "vfs helper functions".
(Or, more simply, kernel code can rewrite the call to the LSM check to no-op
like funny workaround for vmsplice's vulnerability).

I think attempt to receive the vfsmount from kernel code won't help guaranteeing that
LSM's security checks are always performed.
Routes to access "vfs functions" from kernel code is undeterminable.
In other words, LSM can't guarantee that LSM's security checks are always performed
against the kernel code regardless of the security model.

But, at least, LSM can guarantee that LSM's security checks are always performed
against the userland code regardless of the security model.
Routes to access "vfs functions" from userland code is determinable.

So, making the vfsmount available to LSM make sense.
I don't care if the vfsmount is unavailable when the vfs helper function call was
issued from kernel code.
--
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/