Re: [Visualpython-users] UPDATE: High School Network Security

[Andrew D. <dou...@la...>]

On Mon, 16 May 2005, Frank Noschese wrote:

> Thanks to everyone that gave input to my Vpython installation roadblock. Like
> Arthur said, this is not a situation which will be fixed by a little
> "education."

I agree.  Although you'll need facts in hand, you'll probably also need a 
higher-up ally -- someone who has the authority to have the IT folks 
re-examine the issue.

Bear in mind that computer and network security are quite important, 
especially if student records are kept on the same network.  (Ideally, 
academic and administrative networks should be cleanly separated, but in 
practice I'll bet they often aren't.)  If a compromise of the computer 
network could result in the leaking of private student data, then network 
administrators indeed should be paranoid.

Nevertheless, the computer system is there to serve the educational 
mission of the school, not the other way around, so if there are strong 
educational reasons to install a particular software package, then that 
package deserves an honest test and evaluation based on it's individual 
importance, track record and performance under testing.  Of course, the 
tech department probably doesn't have enough staff to adequately do that, 
so it may prove difficult to get anything done in a timely fashion.

For the most part, the tech coordinator's reasons apply to both open 
source and non-open source software (I give details below).  I'd expect 
him or her to want to carefully test *any* software before installing it 
on the network, but if it passes that testing, I fail to see why it 
couldn't be used.

Hmm.  Would the tech coordinator be happier if you bought a version of 
Python from Activestate  ( http://www.activestate.com ) ? 

Here are some detailed thoughts, drawn in part from my long-time 
involvement in Open Source software:

>  I asked the tech coordinator to outline the reasons why installing
> open source is not in the school's best interest. Here is the reply:
 
> "In Reference to our ticket #313, there are a number of reasons why we (the
> technical team) decided that it would not be in keeping with the "best
> practices" of the district to install open source software on the districts
> computers and network. Four key reasons are as follows:

> 1) Lack of technical support from the 'vendor'.

True, there's no guaranteed technical support.  But that's not unique to 
Open Source software.  I have plenty of commercial software that has no 
technical support (for example, the company has gone bankrupt, or our 
support license expired, etc.)  Other software supposedly has commerical 
support, but it's worse than useless.  (By that, I mean you waste a lot of 
time only to run into a brick wall at the end anyway.)

There ought to be a way to get software installed "unsupported".  That is, 
the tech department would not be responsible for handling calls related to 
the use of the software.

> 2) Product testing was another reason. Since there are so many contributors to
> open source software, in many cases, the software is not tested for
> compatibility and stability. As such, there is no level of expectation that the
> product will function as stated. Further more, with the limited testing of the
> software, we have no idea of what problems or ill effects the software may have
> on the computers and network.

That's true for much commercial software as well, particularly the more 
specialized software used by particular academic disciplines.  I could 
cite numerous examples if needed.  All software installed on your school's 
network should be tested to make sure it works there.

> 3) Legal issues. According to the American Bar Association, Contributors do not
> vouch for the cleanliness of the code they contribute to the project; in fact,
> the opposite is true -- the standard open source license is designed to be very
> protective of the contributor. The typical license form does not include any
> intellectual property representations, warranties or indemnities in favor of
> the licensee; it contains a broad disclaimer of all warranties that benefits
> the licensor/contributors. Seeing in that there is no way for us to verify that
> the code that contributors are adding is there own, we may be opening up the
> district to legal actions should the software or portions there of are
> copyrighted and being used illegally or improperly. See attachment for more
> detail...

If this applies at all, it applies equally to both Open Source and 
proprietary software.  Most software comes with similarly broad 
disclaimers.  For example, both commercial and open source "vendors" had 
to deal with the issues surrounding the Unisys LZW compression patent.
End users such as school districts were not held responsible.

> 4) Security of the "system." Since in most cases, anyone can obtain a copy of
> the source code of the software (OPEN SOURCE), we are running the risk of a
> user being able to modify the software on the network and manipulated it in
> such a manor to produce undesired effects.

This is just wrong.  The copy on the network can't be modified unless it 
is installed improperly or the network is configured incorrectly.  
Whether or not a copy on the network can be modified is independent of 
whether or not the original product was open source.  If users are able to 
modify installed software, then all software installed on the network is 
at risk.  This has nothing to do with whether or not it is open source.

Security of a system is indeed an appropriate concern.  It is quite 
appropriate for the tech coordinator to evaluate the security risks of any 
software being installed on a network.  However, that evaluation should be 
based on the track record of the particular software as well as the 
relative importance of that particular software to the overall mission of 
the institution.  For example, many places still allow the use of 
Microsoft Outlook and Internet Explorer, judging that their usefulness 
outweighs the security issues.

>  Another security concern is the ability of virus introduction. Since the
> source code is open, anyone so inclined, could create a virus to exploit the
> software without much difficulty. This ability to introduce a virus or other
> malicious code to the system can have the effect of bringing the system "down"
> and possible data loss or corruption."

The phrase "without much difficulty" is not justified, and not probably 
applicable to Python.  Though this is a valid theoretical concern, it 
needs to be backed up by an actual examination of the particular software 
in mind. Judging from the incidences of actual viruses, it's probably much 
easier to infect Outlook Express or Internet Explorer than it is to infect 
Python.

In short, I think that the blanket rejection of open source software is 
based on false assumptions and is bad policy.  But it's also policy that 
it may be difficult (politically) for you to do anything about -- after 
all, you may have to work with these folks for years to come.

> Any thoughts from you folks? Do they have any truly valid points? Perhaps a
> "Live CD" is my best (only?) option.

I can't imagine that suddenly booting up a lab full of Linux workstations 
would go over much better with the tech coordinator :-).  I don't 
understand Windows installation issues enough to know if one could build 
an entire Python + Vpython tree on a CD and just run that, but that's 
probably the direction I would head first.

-- 
    Andy Dougherty		dou...@la...
    Dept. of Physics
    Lafayette College, Easton PA 18042