Casper and DeepFreeze

Forgive me a silly question, but if the kids aren't admins, how are they
creating admin accounts? And if they are adminsŠwhy?

B

-- Brian J. Little

Macintosh Computing Analyst: ACTC, ACMT
Davidson College
Information Technology Services
213 N. Main St., Box 7164
Davidson, NC 28035
http://forum.davidson.edu/fieldnotes
704-894-2429

if its a Mac in the hands of somebody becoming an admin is less than hard
with netboot, target disk mode, the lion recovery partition there are at
least 3 simple ways to turn yourself into an admin.
-- Todd Ness
Technology Consultant/Non-Windows Services
Americas Regional Delivery Engineering
HP Enterprise Services

Not arguing, just thinking aloud.

Netboot: Controllable fairly simply, and without DeepFreeze
TDM: Blocked by firmware pw
LRP: Not sure if this is blockable, but even so, it's not required. Don't
use it (I'm figuring "don't use" is cheaper than "buy DeepFreeze")

Of course, as someone pointed out to me on another forum there's also the
RAM hack. Galen, are these new machines?

-- Brian J. Little

Macintosh Computing Analyst: ACTC, ACMT
Davidson College
Information Technology Services
213 N. Main St., Box 7164
Davidson, NC 28035
http://forum.davidson.edu/fieldnotes
704-894-2429

Galen,

On year 5 of our 1 to 1 here in KCK. I too had this exact same problem. I use extension attributes to detect local admin accounts on student machines and then run reports of kids that have broken AUP and give them to building administrators. Then students are punished accordingly for breaking the AUP. With them taking the laptops off campus and having physical access there is no good way to prevent this from happening. Except on the newer hardware Macs which actually require that you have the old (current) firmware password to clear it or change it, or contact Apple support to get the hash key to disable it. No longer does removing a stick of RAM clear the firmware password.

It sounds to me like you want to throw money and an extra layer of technology on a problem that can be solved by process and policy. Build a process to create policy that will detect if students break the AUP and then facilitate a way for the administrators to deal with those students that violate the AUP.

Then on the technology side build a process/work flow of deploying software, and the OS in a modular fashion so you can adapt and improvise on these sort of things on the fly. Give non IT staff a local admin accounts that are separate and can be nuked if compromised. I know that working in high tech education the technology side is most definitely enterprise, but the user side is not. They are not employees, they are not assets to a company. They are students and teachers. So the line sort of blurs. You may have to give principals and directors local admin access for ARD or for authoritative reasons - trust me I have been there. So, if you design it properly you can adjust and implement solutions with out having to spend money on products like deep freeze.

Deep freeze will also add yet another layer of technology onto your current solution making it more complicated. My opinion is to use a process to build policy to detect AUP violations and work with all the administrative staff enforce AUP and discipline violations. Once students start getting detentions, in school suspensions and worse a lot of them will stop.

Just my 2 cents, Tom

Tom-

Sounds like addressing a social problem with a technical solution ;)

j
---
Jared F. Nichols
Desktop Engineer, Client Services
Information Services Department
MIT Lincoln Laboratory
244 Wood Street
Lexington, Massachusetts 02420
781.981.5436

Not arguing either, but...
Lion Recovery Disk Assistant <http://support.apple.com/kb/dl1433>
this little free download makes the fact that you have no LRP irrelevant.
and firmware passwords can be turned off by anybody with a screwdriver
right? that's part of the original email removing firmware passwords.
face it you can only do so much, you can add scripts and launchdaemons to
remove anything added to the admin account before they could ever login
and make it useful, but if they can figure all this out they are going to
find your script. you could set stuff in MCX or Casper to fix things, but
they could remove that as well.
if its serious enough of a problem you have to manage it through
discipline I would think. monitor it, give em detention, or fail them
whatever.

-- Todd Ness
Technology Consultant/Non-Windows Services
Americas Regional Delivery Engineering
HP Enterprise Services
Telephone +1(720) 475-6358

Email todd.ness at hp.com
applewebdata://854A2179-8596-47BF-AD43-6E291368E743/todd.ness@hp.com
5268 E. 118th Pl. Thornton, CO 80233

I need to print a T-Shirt that says that and start handing it out, then have it quoted by J-Nix

-Tom

Yeah, preaching to the choir on this one. If only IT departments ran the world.

Galen

We are well aware that if a student has physical access, we can't prevent this kind of thing happening 100%. I just have a request from the top, and I am currently looking into options.

The computers that we have had the issues on were older ones, purchased about three years ago, I believe. The RAM hack is how they got around the firmware password. So it might be only an issue with the older computers, if I understand some posts correctly?

I have had some kids get around our filter, and install software, by changing, and moving some system files around. That was the other reason for looking at a DeepFreeze solution, as once one kid knows how to get around the filter, the rest will within a couple hours. So that was another reason we wanted to lock the system down a little further.

Galen

Deep Freeze will not prevent the removing the RAM trick and rooting the
machine. What students do is remove the RAM to clear firmware, then
boot into SUM (which runs as root) then delete the
/var/db/.AppleSetupDone file and create their own admin account. Deep
Freeze will not run at the firmware level nor will it run in Single User
Mode since all third party apps are disabled in it.

So, really, setting up a process to detect AUP violations and getting
that information to those in charge of discipline is really the best way
to go in my experience.

-Tom

I'm just going to throw this out there since it's the model we use and
it's *mostly* working for us. I've had conversations with Tom and
others both on and off this list about the pros and cons...

Have you considered building your 1:1 program so that your end-users
are administrators of their laptops?

I know, it's not the standard model, but here me out. Here are some
pros and cons:

PROS
- it provides a sense of "ownership" to our student body. They are
less likely to go out and purchase another laptop for use (there's no
"school laptop" and "my laptop" dichotomy). The school-issued laptop
*is* their laptop. They are allowed to install applications, make
changes (within reason), and treat it exactly as if they had gone to
the Apple Store to buy their own laptop.
- it reinforces "real-world" technology life skills. Students are
expected to keep their computers up-to-date using Software Update,
Adobe Updater, and Microsoft Updater. I still package up things like
Flash, Flip4Mac and some smaller tools that are present on all our
machines, but most of the updating is *not* done via JSS.
- they are allowed and even encouraged to install applications that
can assist their studies. Quite a few apps we now use on all our
computers were discovered, piloted, and championed by our Laptop
Leadership Students who test almost everything for us: Caffeine,
Flux, Evernote, Genius, and more.

CONS
- there's a lot of "cleanup" that I end up doing. Particularly at our
Middle School, we have curious students wander into trouble areas of
technology that end up hosing their machine. Our students know that if
they break their computer because they were messing around, that the
machine will get imaged and they'll have ot start all over again. I
spend a fair amount of time imaging messed up machines (I usually pull
the profile across from Time Machine backup, but only the profile, not
their Apps).
- it involves a great deal of documentation. Our AUP is constantly
being revised to include things that pop up that we were unaware of.
Student know that that AUP is flexible and it's written with language
that allows us to interpret it to help us with the inevitable
violations that occur.

Of course, we don't allow our student to use P2P software while on the
school's network. Our firewall (Untangle) allows us to detect this. We
also don't allow them to create other administrator accounts on the
machine. We don't allow them to upgrade their own operating system
(i.e. to Lion). And we don't allow them to run Parallels, VMWare, or
other virtualization software like Boot Camp that would allow them to
bring an infected Windows installation onto our network. This is all
outlined in our AUP.

Also, every student is required, twice a year, to take what we call a
Technology Driver's Test. Just like learning to drive a car, we train
our students to be responsible technology users and good netizens. We
have a Driver's Manual here that you can look at:
http://driversmanual.mka.org/

When I tell other tech people that I manage a fleet of 1000+ Macs and
that every user is an Administrator on their own machine, I get looks
of disbelief. In some ways it's a technology support nightmare. In
other ways, it's liberating that I don't have to try to keep parity
between every single laptop.

In the beginning, I was *not* on board with this idea. I thought it
was going to be disastrous and unsupportable, but it turns out not to
be the case. I lobbied for much tighter control of these laptops but
was overruled. Yes, it makes for some interesting challenges, but it's
working out very well. I think that with adequate technological
training of your faculty and student bodies, a well-written AUP, and
an administration that understands the realm of educational
technology, allowing your students to be administrators of their own
laptops can be a workable solution.

And no, this would never ever ever work with a pool of Windows laptops...

Hope this helps. I'd be happy to answer any other questions about how
we build this program and how we administer it. We also welcome any
visitors that would like to come see what we've done.

Damien Barrett
System Technician
The Montclair Kimberley Academy
Montclair, NJ 07042
973-842-2812

Thanks for the reply.

I work for a privately owned company that has no governance in place.

Something like what you've described would work though...

Just not sure of the legality of letting users install apps on the macs that are licensed to them.

Food for thought though!

Regards,

Ben.

That is a really interesting concept. I personally would not be
opposed to the idea as long as I wasn't responsible for anything the
user did, or had to hold their hand and also be forced to support a
plethora of random open source apps the students kept installing.

The main reason I would say no is because educational software
developers are just down right horrible. Our online text books only
work in Safari and only with version 5.01. No other browser works and
no other Safari version works. How can I have quality control if users
can run software update? How can I ensure what updates need to be
applied and what need to be avoided? Not to mention how many times does
a bad installer botch permissions? They run an installer as their admin
and suddenly they own files and folders in file paths they shouldn't
because the installer doesn't properly deploy permissions (composer
fixes this)

This is what self service is for. Users request optional software and
software updates and I enabled it on self service after I verify the
license is free, or we paid for it and it actually works with the
system.

Security - you can pretty much honestly throw away all security,
including the Casper account. With admin access they can root,
uninstall the filter client (required by federal law, see CIPA),
uninstall our anti theft tracking software, and this all ties into
eRate. If our E-Rate rating drops then we no longer qualify for it,
which is a huge not gonna happen here. You also run the risk of the
smart kids installing hacking tools like nmap, and backtrack and so
forth. We have had some smart kids in our 1 to 1 program. One even got
a full ride to MIT. I have caught these kids hacking the systems more
than once over the past 5 years.

Lastly, and most important in my view, is you completely get rid of
quality assurance when users run as admin.

-Tom

Allowing students to have administrative access is a dynamic that has been brought up before, but was very quickly shot down by pretty much everyone but the person that brought it up. I am not saying it is a bad idea, I personally believe that digital citizenship, and being responsible are incredibly important to teach students. I know that in some districts it could work out wonderful, as I have a friend that has done this with success. However, I don't know if our staff are quite ready for that yet. We are just getting our feet wet with the one to one program right now, and to add it this soon might make them a bit irritable. I do see the benefits to both sides, and I know that it will come up again in the future once the dust has settled. When that does happen it will be an interesting conversation, but it is encouraging to hear what the issues are.

Galen

On Nov 18, 2011, at 12:01 PM, Thomas Larkin wrote:

That is a really interesting concept. I personally would not be opposed to the idea as long as I wasn't responsible for anything the user did, or had to hold their hand and also be forced to support a plethora of random open source apps the students kept installing.

The main reason I would say no is because educational software developers are just down right horrible. Our online text books only work in Safari and only with version 5.01. No other browser works and no other Safari version works. How can I have quality control if users can run software update? How can I ensure what updates need to be applied and what need to be avoided? Not to mention how many times does a bad installer botch permissions? They run an installer as their admin and suddenly they own files and folders in file paths they shouldn't because the installer doesn't properly deploy permissions (composer fixes this)

This is what self service is for. Users request optional software and software updates and I enabled it on self service after I verify the license is free, or we paid for it and it actually works with the system.

Security - you can pretty much honestly throw away all security, including the Casper account. With admin access they can root, uninstall the filter client (required by federal law, see CIPA), uninstall our anti theft tracking software, and this all ties into eRate. If our E-Rate rating drops then we no longer qualify for it, which is a huge not gonna happen here. You also run the risk of the smart kids installing hacking tools like nmap, and backtrack and so forth. We have had some smart kids in our 1 to 1 program. One even got a full ride to MIT. I have caught these kids hacking the systems more than once over the past 5 years.

Lastly, and most important in my view, is you completely get rid of quality assurance when users run as admin.

-Tom