On Mon, Mar 28, 2005 at 05:19:30PM +1000, wrote: > Jakob Bohm 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.