Re: harden-debian script?

[JimcDTWlst@aol.com]

In a message dated 10/25/00 6:53:44 PM Eastern Daylight Time, nate@campin.net 
writes:

> 
>  After I install new debian boxes the permissions are always something
>  like 755. This is bad in my opinion, for a multiuser box. On firewalls,
>  however, there should be very few people logging in at all and then only
>  to administer the box, not to read mail or anything like that. Therefore
>  this isn't much of an issue for firewall installs.
>  
>  Does anyone know why debian has such lax perms on home dirs?
>  


The way "we" have handled this (for many years) is:

write a crummy little shell script to add your desire to a command (later you 
can add more and have it ask you to choose what you want it to do and then 
execute some block of commands accordingly)

chmod that file for the maximum restrictions of it's power (which can/should 
have some added additional sensible defaults and traps inside it, you add 
these after it works w/a single chmod of $1 or etc., while it's still 
crummy/little, then as it gets bigger you can always re-place its function in 
additional files/calls)

mkdir /usr/local/sbin or better /usr/local/adm/sec

chmod that so that ONLY you can "see" it (x permission on a directory is 
search/see ability for ug&o; no w for anyone (you chmod write perm for yoy 
only, back "onto" for any maint. session (and inside the script, make sure it 
exits AND traps w/re-set/affirm chmods on script(s) and dir)

for your usual userid (this should be root only, unless you have a semi-root 
trust/power system; or create new user to just do these types of things by 
user/group tuple

        whom have their PATH be the only PATH that puts the created dir within

        consider calling it "adduser" and putting it in the dir mentioned 
above, on your path before the real adduser
            so it first calls the real adduser and then does/adds your other 
stuff too (pre/post/whatever actually, even redirect output strings to logs 
of              before/after copies)
.

Thus, you can roll your own (your enhanced) adduser and bottle it up nicely 

I do a lot of this sort of thing in a directory that is first on my PATH.  A 
"rm" that saves to another file system (other file-system)/usr/rms (w/a cron 
size warner) for example,  and scripts named 1(ls -l"$@"|less),1t(ls 
-lrt|less), 2, 3, 4, 5, 6, 7(file "$@"|less), 8, 9, 0, a, t(date), c, z, q,  
etc. (especially the keys you can hit fast w/o "fat finger" effect).  Then 
you slap your own hot key w/a RETURN and haul!

"pwd <RETURN>" is ok, but the pinky fingers are unreliable at high speed and 
"reaching" for me and others, so I use "z <RETURN>" instead cause my left 
pinky finger is reliable w/ a simple tuck, instead of a reach.

"alias" can do this but is much less self documenting and not available in 
all legacy shells and .*IXs.

I keep this (my hot keys) dir on a floppy to take to any system I end up 
working on, bc. I get soooo empowered by my familiarity w/them (I love this 
speed!), I am frustrated as heck whenever they are'nt "at hand" :) .

IMHO, many commands standardly allowed "all"/"some" need rethinking for a 
secure system and it's so easy to apply additional/other/totally-new 
restraints and
abilities by (re)"wrapping"  what's there, incorporating PATH w/permissions, 
execs, sub-shells etc.

Forgive any lack of lucidity, I wrote this while I was supposed to have moved 
on to other expectations of others.  It's only email.  A forum for'em.

Regards,

Jim Cunningham