Re: Re: Help

[wsykes@bigfoot.com]

Way to go, Daniel. I used to work in the help desk side of the computer industry and 
most of the people working there were 18 and up. The 18-21 crowd knew more 
about programming and the software side of computers than did most of the "older", 
45 and up, crowd did. Especially the new languages and such. Don't underestimate 
today's youth. They WILL surprise you.



On 4 May 2002 at 22:53, Daniel Fairhead wrote:

> > Secondly, with response to the original post, I think that there is an
> > unjustified level of paranoia by the network admin. High school children
> > are at best going to be script kiddies. Secondly, your school should
> 
> Not so. I'm 15, admin my own linux box and am a developer on the CronosII
> email client.  I read debian-security and keep my machine reasonably up to date
> and secure, using a self-written ipchains firewall, snort, and all security measures
> mentioned in the FAQs and HOWTOs. I'll admit, I'm home-educated, not schooled, 
> so I may not be a typical High-School student, but saying that just because someone 
> is High-School age means they cannot be just as good a cracker, or system-admin,
> or programmer, as adults.
> 
> I have not met many younger members of "the Dark side" of computing, but I am sure
> that more than just basic script-kiddie knowlage and skill is out there.
> 
> Besides, who is to say that a teacher might not try and do something malicious? Or an
> older brother/family member of a student? Or a total outsider who managed to get in?
> At open-days and such non-school members are allowed to walk around most schools,
> and see the computer labs, play with the software there, and other such activities. If a
> school had wireless networking set up for staff with laptops then a drive-by might even
> be possible.
> 
> At the primary school I went to in the UK, there was a grade-5 boy who was far more
> compertant than the local system-admin/security expert, and often was called in by the
> teachers to fix problems such as printers not working, and while doing such, occasionly
> managed to screw things up "by accident". It was a windows 9x based setup, so not a
> huge ammount of knowlage is needed to screw things up, but now (I hear from my brother
> who is a friend of his) that he is running his own linux system at home.
> 
> > have an ethics agreement between the children and the school (signed by
> > parents) binding the users to a legal agreement of use.
> 
> I know I would respect that, and most kids would. If they understood it. I think
> perhaps signed by the children as well might be an idea, because then they would
> have personal responsibility to the agreement, and would add a certain "adult" element
> to it which would not be there if their parents only signed it.
> 
> > With that in place, I'd like to see how many of your students dare try
> > anything on your computers knowing that they can be expelled for
> > breaching the agreement.
> 
> *grins* I wouldn't! However, from the original it sounds as if C is worried about students scripts
> being run on the server... could students have to explicitly ask for shell permission (which would
> reduce the number of people in a "suspectable" list in case of a problem) and then be told that
> they are responsible for that user. On the same note, disallowing exec on the /home and on /tmp 
> and making "sh"/BASH/perl/etc only able to run in interactive mode for students would solve that
> problem.
> 
> > Lastly, install bsd process accounting and inform students that all their
> > actions are being logged.
> 
> Just informing them would probably be enough. But putting the occasional warning about the
> system, in the first-time sudo message, or in the MOTD or /etc/issue(.net) would be a good
> idea so there is no way someone could say "I didn't know about the agreement!", and mention
> specifially about students being disallowed, not just the normal default messages, because then
> it shows that the system has been setup/configured not just installed and left.
> 
> Daniel
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-security-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> 
> 



-- 
To UNSUBSCRIBE, email to debian-security-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org