>> Is this feature seldom used, so we do not care much about it; or is
>> it often used, and so possibly worth retaining?
>
> I certainly use it. I also create multiple ... 'almost root' accounts ...
You are smart enough to set up features similar to group staff, and do
not need group staff to be available *by default*.
> The real, fundamental, security issue is that most
> implementations of the NFS protocol ...
Group staff and NFS should not co-exist. Which one should Debian policy
warn against? Debian policy does not force you to use NFS, it must not
force you to have group staff either.
> These broken-by-design NFS implementations ... trojanize all user
> writable files ... all systems should be given the 'root compromise'
> cleanup.
Not quite as bad as that: root-squash should protect you somewhat.
>> Is it documented anywhere that you should only give group staff
>> privileges to those that also have the root password?
>
> I think it is probably documented somewhere (and certainly basic
> os-independent sysadmin knowledge) ...
Specific reference, please. Is it documented by Debian, in the policy
that forces group staff upon you?
>> At no time was I arguing for banning whatever ownership of /usr/local
>> by policy; I only wanted to also allow it being owned by root. ...
>> ... However, you must also grant me the right to run my machine
>> securely, and should not try to prevent me from doing so by policy.
>
> NOT agreed. ...
Do you really mean that? Which one do you mean: should policy
specifically disallow root ownership of /usr/local, or should it prevent
me from running my machine in a way that I (foolishly) think is safe?
> The problem is that most NFS-servers and most versions of the
> NFS protocol do not perform sufficient validation ...
NFS may be ugly and insecure. Should we banish it from Debian?
Jakob Bohm <email address hidden> wrote:
>> Is this feature seldom used, so we do not care much about it; or is
>> it often used, and so possibly worth retaining?
>
> I certainly use it. I also create multiple ... 'almost root' accounts ...
You are smart enough to set up features similar to group staff, and do
not need group staff to be available *by default*.
> The real, fundamental, security issue is that most
> implementations of the NFS protocol ...
Group staff and NFS should not co-exist. Which one should Debian policy
warn against? Debian policy does not force you to use NFS, it must not
force you to have group staff either.
> These broken-by-design NFS implementations ... trojanize all user
> writable files ... all systems should be given the 'root compromise'
> cleanup.
Not quite as bad as that: root-squash should protect you somewhat.
>> Is it documented anywhere that you should only give group staff
>> privileges to those that also have the root password?
>
> I think it is probably documented somewhere (and certainly basic
> os-independent sysadmin knowledge) ...
Specific reference, please. Is it documented by Debian, in the policy
that forces group staff upon you?
>> At no time was I arguing for banning whatever ownership of /usr/local
>> by policy; I only wanted to also allow it being owned by root. ...
>> ... However, you must also grant me the right to run my machine
>> securely, and should not try to prevent me from doing so by policy.
>
> NOT agreed. ...
Do you really mean that? Which one do you mean: should policy
specifically disallow root ownership of /usr/local, or should it prevent
me from running my machine in a way that I (foolishly) think is safe?
> The problem is that most NFS-servers and most versions of the
> NFS protocol do not perform sufficient validation ...
NFS may be ugly and insecure. Should we banish it from Debian?
Cheers,
Paul Szabo <email address hidden> http:// www.maths. usyd.edu. au/u/psz/
School of Mathematics and Statistics University of Sydney Australia