full-disclosure - /bin/rm file access vulnerability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks@...edu)
Subject: /bin/rm file access vulnerability 

On Thu, 30 Dec 2004 12:52:23 -0400, Jerry said:
> I have to agree with Shane on this.  The whole point of the admin a.k.a root
> user is to have full control over everything.  What's the point of that user
> if it can't delete of stop a set process when required if some user orphans
> something and can't get it back?

If you are in an environment that cares about security, one user having full
control is a Bad Thing.  And it's not just military sites either - one of the
first rules of accounting and auditing is that if one person is writing checks,
somebody *else* actually balances the books.

One common enhancement in Unix systems for high security is splitting out
what userids can run what commands, and getting rid of the "root" user entirely.
So for instance, one userid may be able to run the backup and restore commands,
but nothing else.  Meanwhile, you might have a "sysadmin" userid that can
kill processes and remove temp files - but which *cannot* alter the system
auditing settings - so if the sysadmin does something they shouldn't, it's
in the audit trail where it will be seen by the security admin.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050101/9927e054/attachment.bin