On Mon, 21 Mar 2005 06:55:58 +1100, psz <[EMAIL PROTECTED]> said:
> Manoj Srivastava <[EMAIL PROTECTED]> wrote:
>>> Sorry, but that is not the issue. The attacked machine would not
>>> be an exporter, but a mounter of user files.
>>
>> Umm. The exporter is the one that got attacked, since it has the
>> data. every other user that mounts the file system is collateral
>> damage.
> As far as the exporter is concerned, the creation of a setgid-staff
> object may be perfectly legitimate: it may have group staff == GID
> 50 as a "normal" user group; it may not have any "local" users or
> user access; it may have the exported tree contained within a
> filesystem mounted nosuid. (The exporter may be a
> NetworkAttachedStorage device without any understanding of users or
> groups, and without an attackable operating system.) The exporter is
> protected against root attacks by its use of root_squash. It is the
> "collateral damage" on the mounters, through the root-equivalence of
> group staff, that is a root attack.
> It is the responsibility of (the manager of) the mounter machine to
> protect its (own) security, regardless of any attacks on other
> mounters on on the exporter.
Quite. And having a policy of non group staff writable
directories on the client does no good, if the server exporting it
has such a policy. Indeed, if the server has gid staff writable
directories, you can have base-files set whatever it wants to at
install time on the client: as soon as the /usr/local is mounted, the
servers setting trumps everything.
This is purely a server side policy issue. If you can't
understand that, there is not much point in carrying this discussion
farther.
> In my example, I properly and legitimately own /users/psz. If I can
> "get" group staff on one machine (e.g. because I "got root" there)
> then I can create a setgid-staff file /users/psz/attack and "get
> root" on any other Debian mounters.
If the exporter sets the all squash or group squash in the
exports file, you would not be able to do that. Not squashing root
or gid's from the client side isthe serever explicitly giving
permission for the root on client machines the ability to modify the
exported /usr/local filesystem; if that is not what you desire, do
not configure it like that.
> Though nfs-user-server may "know" about the squash_gids option,
> nfs-kernel-server does not.
It has all squash options instead.
> Finer control of privileges is useful when they are not
> root-equivalent. Group staff becomes a security issue once there
> are users in that group (and is useless otherwise). Users in group
> staff are root-equivalent, defeating the purpose of finer control.
Rubish. Allowing some entity to modify /usr/local is not the
same as allowing them to reload my Se-Linux policy, or to change my
/etc/bind settings. They are root equivalent in limited sense, which
is what is desired. If ever I export /usr/local without squashing
root and gid's, I have given explicit permission to remote root users
to modifymy /usr/local file system.
When I do not trust the remote machines, or the users, I take
due precautions: either export it read only, or squash permissions.
> The crux of the matter is that group staff cannot be used. If it
> cannot be used then it should be ditched, regardless of whether it
> is a security risk while there are no users in that group.
I do not see how this follows. When I give give others, or
take on the role myself, by entering the staff group, either
directly, or as root of a remote machine that mounts my file system
read-write, I am taking on a priviledge that was knowingly granted. I
know I can install CPAN modules, but not harm things outside these
trees. Making users install CPAM modles as root by taking away the
ability to do so as grou staff is even worse a security issue.
> Read-only exports do not mitigate the attack (the attacker could get
> group staff on the exporter).
They could get root on the exporter, and you are SOL then too.
> Requiring squash_gids on the exporter would ban the mounting from
> non-Debian exporters.
Non Debian exporters are out of the scope of this policy; they
can do whatever they want.
> Anyway, the attack involving NFS was just a demonstration that
> having /usr/local group-staff-writable is a security risk even when
> there are no users in group staff.
Having users is a security risk. Indeed, any network
connection is also a security risk. Anything that makes the machine
useable is a security risk. By itself, this is not much of an
argument.
>>>> The common case by far benefits from /usr/local not requiring
>>>> uid=0 to modify; and we should be making things easier for the
>>>> common case, and not too much harder for the uncommon.
> Would you please specify what is the common case? Could you please
> explain how it is protected?
The common case is where no file is exported, and no one
except perhaps permitted users are ever in group staff. The roles
that have groiup staff in them are meant to be used to modify
/usr/local; and are thus _staff_; and can do their work without
needing to escalate their privilegesto that of the super user.
manoj
--
"Show business is just like high school, except you get paid." Martin Mull
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
