Security Plan

[David Webster <cog@seul.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is a plan I've worked up to improve Indy's security. Comments are
more than welcome.

- - Remove ALL services, unless otherwise authorised by user during install.

- - Remove as many SUIDs as possible. (Is removing ALL possible?)

- - The three 'r' utilities are big problems, don't install by default,
inform user of problems with them before letting the user install them.

- - Stop remote printing ability, unless asked for by user.

- - For the admin utilities (fdisk, etc.) move away from 755, to 510.

? - Collect similar commands into 'groups', assign group name to that
collection of commands, and if a user needs to have that functionallity,
add them to that group (provide easy way for root-user to add other users
to groups). (i.e. have groups: local (for users accessing from terminal) 
remote (if install is server, for remote users), printing, admin, etc...) 
[Unsure about this one. Anyone any thoughts?]

- - firewall set to DENY, unless service is explicitly asked for

- - GUI Tool for setting up logs. [Any log monitoring software out there?]

- - Get firewall to log requests/detect portscans, and warn user.

- - Suggest against use of telnet, include ssh.

- - Promote use of GPG/encryption software, include intergration for all
mail readers, if possible.

- - make the default umask 027

- - Introduce single user groups. (i.e. when a user gets added to a system,
a group with that name( or similar if existing) is made, and the new user
is added to groups that the need to be in.

Specifics:

- - change:	/etc from 755 to 711
		/tmp & /var/tmp from 1777 to 1733
			(should control race conditions and snooping)
		/etc/rc.d/init.d to 700
		/bin/rpm to 700

This is just a quick start, I don't know what Indy has already done, so
feel free to tell me if an idea is already implimented, or ruled out for
some reason.

This could probably do with being added to, and will be, once I come up
with more ideas. 

After talking to Jericho (Brian Martin), he thinks that this should rule
out over 95% of the attack possibilities.

As we should with every thing Indy does, the user will need to be informed
of everything the system has done, what is running by default, what checks
are taking place, what activities are cron'ed, etc. Indy should let the
user know what is happening. It should make it easy for the user to do
stuff, but it need not hide what *exactly* is being done.

Once the box is set up securely (our first priority), we should prvidethe
user with tools that make adapting/checking the security policy easier.
Tools like log monitors, facilities like cron'ed checks for SUIDs, regular
checksum checks (weekly?).

That's all for now, as I need /some/ sleep!

David
- --		   ,------------------------------,
,==================| S H U N  A N T I O N L I N E |=================,
| David M. Webster '------------------------------' (aka cogNiTioN) |
|===| I use Linux everyday to up my productivity - so up yours! |===|
|=================|-| PGP KeyID: 0x 45 FA C2 83 |-|=================|
| <cognition@bigfoot.com> |-|===========|-| http://www.cognite.net/ |
`===========| I walk to the beat of a different drummer |==========='
-----BEGIN PGP SIGNATURE-----
Comment: David Webster (aka cogNiTioN) <http://www.cognite.net/>

iD8DBQE4ScrpDdLNO0X6woMRAj3+AKDgr8b7lg1t4EnD7w3COaxBG6yKfACbBW5Z
OKbGPLPuIfLYkI6AKkCpItk=
=lG1z
-----END PGP SIGNATURE-----