On Thu, Aug 31, 2006 at 10:49:10PM +1000, Paul Szabo wrote:
> I am confused: what is the use and intent of root_squash, why is it enabled
> by default, and why is there an option to turn it off?
It's a naive and often circumventable technique for limiting the impact of
an untrusted/compromised client. It can be turned off because sometimes you
don't want it. That answer seems obvious to me.
> Is it documented that NFS must never be used between systems in different
> security contexts, other than that UID/GIDs should match?
I don't know. How is it the responsibility of the kernel to document all
the ways you can misconfigure an NFS environment?
> >> Sorry, as I read Debian policy (and as discussed in #299007), I am not
> >> permitted to change root's PATH or change the permissions on /usr/local.
> > *You* are permitted to do either of these things. Whether they will be done
> > by default in *Debian* is a separate question.
> Could you please point me to where that is documented, and maybe explain
> what does the policy apply to?
Abstract
--------
This manual describes the policy requirements for the Debian GNU/Linux
distribution. This includes the structure and contents of the Debian
archive and several design issues of the operating system, as well as
technical requirements that each package must satisfy to be included
in the distribution.
>From the beginning of the Debian Policy Manual.
> If policy may be ignored, then is there such a thing as a critical bug?
> "Turn it off or fix it yourself and you will be safe": is that good enough?
I think you're being deliberately obtuse by ignoring the distinction between
a root hole that exists as a consequence of *installing or using the
software*, and a hole that exists as a consequence of *how you choose to
configure the software*.
> > Now you're not even talking about anything that can be *fixed* by
> > smash_gids, you're talking about trojaning arbitrary files that will be
> > accessed by individual users on the NFS server. The only way you can guard
> > against a compromised client in that case is to never share home
> > directories of any users you're worried about!
> I am talking about what an attacker can do, once he "gets root" on the
> client. I "trust" my users (to have no skills to attack). And it can be
> fixed: root on the server will be safe if we fix either of the last two
> points, in the policy or if the policy allows us to fix our systems; or
> if at great expense we implement squashing GIDs.
No, there are three vectors by which an attacker on the client can exploit
this problem to get root on the NFS server:
- the server's /usr/local is itself NFS-shared from server to client, and
in the absence of squash_gids the attacker is able to directly trojan
root's path
- a filesystem is shared that allows the attacker to write an suid binary
to the server, and the attacker is able to start arbitrary processes on
the server using credentials of a compromised user account and thereby
trojan root's path, *or* attack through another privileged group
- a filesystem is shared that allows the attacker to write a file to the
server that triggers some other user who is a member of a privileged group
to execute an attack using their privileged group membership; most likely
this would be done via shared home directories and shell startup
configuration.
And in spite of the fact that you've been given *multiple* ways to configure
your systems that would prevent the first two attacks, you insist that a
problem should be treated as "critical" that is an artifact of your chosen
misconfiguration, when the third case is at least as likely as the first two
and can't be fixed at all if you're going to share home directories via NFS
and are unwilling to yourself block these users' access to /usr/local.
> > The answer remains, "don't set your NFS environment up that way."
> The correct answer seems to be fix or ignore the policy.
You're damn well free to ignore the policy when configuring your system. I
have no idea where you got the idea that policy was binding on users.
On Fri, Sep 01, 2006 at 08:01:32AM +1000, Paul Szabo wrote:
> The issue is root compromise of an NFS server. If that is possible then
> it is critical; if it is not possible then the bug is solved. It seems
> logically impossible to downgrade this kind of bugs.
No, this issue is the wishlist request that the kernel support a squash_gids
option. The bugs that would lead to root compromise of an NFS server are
artifacts of your configuration, not flaws in the software provided.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
