Xref: utzoo comp.unix.questions:9471 comp.bugs.sys5:591 Path: utzoo!utgpu!water!watmath!clyde!att!cbnews!lvc From: lvc@cbnews.ATT.COM (Lawrence V. Cipriani) Newsgroups: comp.unix.questions,comp.bugs.sys5 Subject: Re: SVR3 passwd changes mode of passwd file Summary: security policies Message-ID: <1367@cbnews.ATT.COM> Date: 28 Sep 88 13:10:47 GMT References: <3394@dunkshot.mips.COM> <344@stiatl.UUCP> <4827@cbmvax.UUCP> Organization: AT&T Bell Laboratories, Columbus Lines: 27 In article <4827@cbmvax.UUCP>, ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes: > In article <344@stiatl.UUCP> meo@stiatl.UUCP (Miles O'Neal) writes: > >I suggest you tell the complainers to always leave the passwd file > >0444. NOBODY besides root should have access to that > > The complaint here is not about security or lack thereof, it's about > programs undoing the system administrator's actions. I can sympathize with this, as I used to administer many UNIX(R) machines. However, the story we have gotten from our customers (ie. the people that pay the bills), and I imagine that other products have, is that they want the security policies built into the system. Security policies are being implemented in software because that's what the market is demanding. Like it or not administrators are going to lose more ground here. > Where should this "enforced security" end? Should /bin/passwd also > chmod / to 555 mode as well? And what about /etc/? Should "ls" > remove world write permission from /dev/mem if it happens to discover > it? There are programs that are designed to enforce (or at least complain about wrong) file/directory permissions. Some have the capability to be customized site by site. I tend to prefer one that just complains and lets me worry about what it ought to be. -- Larry Cipriani, AT&T Network Systems, Columbus OH, cbnews!lvc lvc@cbnews.ATT.COM