which unix-pc files MUST be writeable by others?

[Mark Sienkiewicz]

In article <672 at cbnewsc.ATT.COM> danl at cbnewsc.ATT.COM (daniel.r.levy) writes:
>In article <17736 at cup.portal.com>, thad at cup.portal.com (Thad P Floryan) writes:
>< the /usr/lib/ua most definitely, so that anyone can do "rm -f /usr/lib/ua/*"
>
>[wipe dat smirk offa you face...]
>
No smirk is necessary.  The user agent is a huge security hole.

>Gee tell me something I don't know.  I'm not asking about what's good UNIX
>security in general (I presume that Wood and Kochan's book is about that, not
>about the 3B1 in particular).  I got plenty of training about that at work.
>What I want to know is, WHAT WILL BREAK when I try to impose conventional ideas
>of UNIX security (please hold the wise cracks) upon a 3B1?  And I'd like to

To make a secure Unixpc, do this:
	1 - Kill the user agent.
	2 - do the things that make a normal Unix machine secure (e.g.
		the stuff in that book).

I did this and the machine works perfectly.  Some experiments revealed that
securing the machine DOES break a number of UA functions, mostly
those related to setting up the machine.

The only non-UA thing I can remember that got broken was cu.  (it
uses /usr/bin/setgetty to edit /etc/inittab.  If you allow setgetty
to work, you allow dialup non-priv users to disable logins on the
console.)  You can fix this by replacing /usr/bin/get{on|off}.sh
with empty files; you just can't dial out if there is a getty on your
phone.

I found that a good compromise was to 1) lock the machine down real
tight [of course, I hated UA]. 2) introduce some new security holes so
I don't have to type su very often.  [e.g. make /etc/mount setuid to root
but make it only executable to a group of trusted users.]