Bug#299007: base-files: Insecure PATH
On Mon, Mar 28, 2005 at 05:19:30PM +1000, psz@maths.usyd.edu.au wrote:
> Jakob Bohm <jbj@image.dk> 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*.
>
Well I am smart enough that in theory I don't need anything at
all to be available by default (not even the operating system),
but each thing not there by default is more work to do, more
room for mistakes and less time to actually use the computer.
> > 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.
>
As I explain later in the mail, killing off group staff will not
save you, you are demanding that we randomly lynch a security
feature for absolutely no gain.
> > 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.
No it will not! If an attacker can trojanize any user or group
account used to do trusted work (such as recompiling kernels or
performing backups or managing disks or mirroring debian or
accessing raw I/O or ...) then that can be used to escalate
further to root. Group staff is just a random example of such a
group or account.
And even if that does not happen, compromising each and every
ordinary user account including those belonging to the sysadmins
is bad enough that all user accessible data of any kind should
be considered suspect and restored / recreated from a point
before the compromise. At that point it is mostly moot if the
root data should be restored too, and one should not bet on root
not being uncompromised but proceed as if it was.
>
> >> 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?
I wrote "probably somewhere" because I have not wasted time
looking for any Debian specific tutorial stating this. The text
you snipped explains why and how I consider this to be something
that belongs in basic training. Its like "don't lend people
keys to anything if they cannot be trusted or cannot keep the
key safe".
Some simple *examples* to illustrate my point:
Debian GNU/Linux woody predefines several groups, of those
These can probably be abused to gain root almost immediately:
root, daemon, sys, adm, disk, kmem, tape, sudo,
dip, backup, operator, shadow, video
These can probably be abused to gain root only by waiting for
something to happen (like root running a trojanized program):
bin, tty, proxy, floppy, src, staff, console
These apparently cannot generally be abused to gain root, but
still allow violating some other aspect of security:
lp, mail, news, uucp, dialout, fax, voice, cdrom, audio,
majordom, postgress, www-data, msql, list, irc, gnats,
utmp, games, qmail
Only two groups are mostly impossible to abuse:
users, nogroup
Microsoft Windows/NT predefines several groups and assignable
privileges and denies direct login is root, of those
These can probably be abused to gain root almost immediately:
Administrators, Domain Admins, Enterprise Admins, Scheme
Admins, Power Users, Server Operators, Backup admins,
Print Admins, Trusted Computing Base, Debug, Firmware,
Back up Files, Restore Files, Add Workstations, Create
Token, Load Driver, Take Ownership
These can probably be used as part of more indirect attacks:
Replicator, Audit, Security, Shutdown, Remote Shutdown,
Change System Time, Create a Pagefile, Create Persistent
Object, Quota, Login as Batch, Login as Service, Profile
Any Process, Profile System, Set Process Token
These are less dangerous:
Guests, Users, Domain Users, Domain Guests, Login from
Net, Login Locally, Bypass traverse checking, Lock Pages,
Priority
>
> >> 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?
>
I do not agree that anything you have posted so far justifies
disallowing /usr/local to be owned by group staff by default.
If you think that chown -R :root /usr /bin /sbin /etc will make
you safer you are free to make that mistake on your own system,
just don't force it on the world.
> > 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?
No, but maybe we should make sure all the Debian-shipped NFS
implementations include all necessary security extensions and
enable those extensions by default. (Actually, doing this on
the central NFS server or SAN device would do the trick nicely).
But failing that, making sure NFS is never present by default is
much better than randomly removing one out of hundreds of
useful, meaningful security settings that might be abused AFTER
a system has become almost completely owned through an NFS
compromise.
Removing /usr/local from group staff is pointless because then
that same chain of arguments would require removing all other
group permissions on anything worth protecting, thus effectively
removing half the Unix/Posix security system (the group half) on
the fickle grounds that some software is not enforcing group
authentication properly.
So far I have seen little in your behavior that follows good
security reporting practice:
You fail to identify which part of a chain of events was the
primary security breach. You fail to consider if the measure
proposed would really have stopped an attacker at that point.
You fail to consider if an extension of your strategy big enough
to stop attackers would do more harm than good. You insist on
posting public security advisories when people are telling you
that you are plain old wrong. You insist on posting to full
disclosure lists before any fix could possibly be released by
any of the Linux or Unix vendors, even if they did agree with
your theory.
Maybe you are simply venturing too far outside your field(s) of
expertise. Tackling complex risk scenarios like the ones you
discuss is a whole discipline in itself and not something one
can handle without a lot of experience in multiple relevant
fields.
--
This message is hastily written, please ignore any unpleasant wordings,
do not consider it a binding commitment, even if its phrasing may
indicate so. Its contents may be deliberately or accidentally untrue.
Trademarks and other things belong to their owners, if any.
Reply to: