The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Security: How we did it



Since there were so many posts regarding security in the last days and so
much what I would consider inaccurate representations. I thought a summary
of how security is handled on our campus would hopefully bring things
into the correct perspective.

Also security holes should not be discussed in public as has been done
with the dosemu issue.

Here is the way we implement security on our Campus.

1. No user has shell access anywhere except on a designated properly
firewalled SHELL Server on a special danger zone network. Since there is a
long history of so many security holes in Unix software (also in Debian
software!) I think its irresponsible to let a regular user on a system
that contains sensitive information or ISP services. The Shell Server is
using NIS with Miquels added protection. Thus regular users cannot get at
the encrypted password unless they first gain superuser access. No
need for Shadow etc. Other precautions have been taken to reduce break in
dangers (such as for example replacing the root password with a *).

Of course we dont run dosemu or similar dangerous software on the Shell
Server. You are crazy if you do.

The Shell Server exports its root directory to the administrative servers.
Administrative access can be handled largely via NFS and rarely is
superuser telnet access to that machine needed at all.

Administration (rarely needed) via the Internet is done via an SSH
connection (somebody might be listening in on us!).

2. Modems are spread out across a couple of other secure machines all
using mgetty/ppp in order to cut out the possibility of users messing
around with modems due to security breaches.
On login they are immediately forced to start pppd if they dialup using
PPP/PAP or if they login with username.ppp (Special patches to the login
program by the way).

3. If they login with their username + password then their session is
transparently redirected to the SHELL Server and they are placed in a user
menu. Thus the daemons controlling the access are inaccessible to that
user + the Shell Server.

4. We have relaxed security for administrators on those secure servers. We
are a limited controllable group in daily communication and we would like
to have our jobs as easy as possible. If someone is running dosemu then it
is us. If someone is running diagnostic services then it is us. We all on
occasion have the need of doing superuser tasks on the network of machines
administered but we want to limit the need for doing so or having a
superuser prompt at all.

I think having a server run regular ISP functions and at the same time
allowing user access on the same machine is not wise and with the current 
prices on hardware that is really not needed. Get a cheap old 486 and 
it can probably handle the necessary Shell Access. Separating things
the way we do allows us to be more loose on security for ourselves.

Certainly there is some way to even circumvent our precautions. But I
think this is the best one can do while keeping the system usable (and
that sadly means you need to have some setuid functionality).

--- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++
--- PGP Public Key  =  FB 9B 31 21 04 1E 3A 33  C7 62 2F C0 CD 81 CA B5 

--
Please respect the confidentiality of material on the debian-private list.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com