| 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
| ||
|
Message-ID: <200501020246.j022kM4g015059@turing-police.cc.vt.edu> 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
Powered by blists - more mailing lists