[KLUG Members] Drive Shield/Deep Freeze for Linux

[Adam Tauno Williams]

> >>> Deep Freeze instantly protects and preserves original computer 
> >>> configurations. Completely invulnerable to hacking, Deep Freeze 
> >>> makes computing environments easier to manage and maintain. 
> >>> Each restart eradicates all changes and resets the computer to 
> >>> its original state, right down to the last byte.
> >>> Protect a single, hundreds, or thousands of computers across a 
> >>> distributed LAN, WAN or over the Internet.
> >I think translucent filesystems will work for you.  Mount the parition read-only
> >and then mount a RAM disk over it?
> Translucent filesystems?  I think I understand conceptually how that 
> would work, but I've never heard of such a thing.  Can you explain how 
> one would implement that?  What the heck would the /etc/fstab entries 
> look like?

Haven't used one in ages;  I'll see if I get a chance to look it up.
I'm fairly certain they became standard in 2.6.

Translucency is basically a read-write media mounted over a read-only
one.  So long as the object doesn't exist on the rw media you see the
object on the ro media.  If open the object read-write it is
transparently copied to the rw media and then operation suceeds.

> >Or just use VMware which does snapshotting exactly like what you describe.
> As long as you've got enough horsepower to run vmware and the Windows 
> underneath it.  And are willing to shell out the licenses.  Not trying 
> to shoot down your solution, just pointing out that it's unlikely to be 
> an ideal one in a lot of environments.

Of course;  just enumerating possibilities (and I wasn't suggesting
running Windows under the VM,  thats just crazy).  We run Linux and
Windows VMs on Linux in production and it works very well.

> >>> Jeremy NOTE:
> >>> The question assumes that M$ Window's problems are Linux problems.
> >>> Maybe better stated that the question assumes that M$ Window's 
> >>> vulnerabilities are Linux vulnerabilities.  File permissions in Linux take
> >>> care of most of this.
> >Windows provides very robust file permissions (assuming you are using NTFS).  It
> >is *NOT* Bill's fault that most ding-bat users add themselves to the
> >Administrators group and then go merrily on their way.
> Two problems with that (at least before we have to take this over to 
> advocacy):  1) In most cases you CAN install stuff on a Windows box 
> without being an administrator, 

Only if the local admin hasn't bother to configure a policy (it isn't
hard).  I have lots of 2000/XP boxes and the user can't so much as
install a browser plugin.

> 2) A few applications (admittedly, most 
> of them are games) won't run without administrator rights, so the users 
> do have to be administrators, and it doesn't fix anything if they're not..

Not to nit-pick; but your wrong.  If an application must be run as
Administrator then IT IS NOT Windows 2000/XP compatible - it better not
have one of those gold stickers on the box or you can report them to M$
for *@&(*#^( advertising.   An application that requires Administrator
privileges is just a half-baked port of a Win9x application and should
never be installed or run on a Windows 2000/XP box.  You should at least
do what I do and write a letter informing the company they should hire
programmers who can read documentation.

As a work around look at running the application with runas or cpau
(sp?),  this lets you run an individual application in a separate
security context (like sudo, only crappier) rather then adding the
user's account to Administrators and opening up the machine to be
trashed by IE.

BUT THERE IS NO EXCUSE FOR NOT BITCHIN' TO THE DEVELOPERS ABOUT SOFTWARE
THAT ****IS**** INCORRECTLY IMPLEMENTED.  I believe in writing one's
congressman frequently and even more frequent verbal lashing of
proprietary software developers.  Both actually work (I've had a federal
congressman call me on my cell phone, and I've had patches suddenly
appear that fix the @#**(@#*(@# run-as-administrator ***BUG***).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://www.kalamazoolinux.org/pipermail/members/attachments/20050606/b80b2276/attachment.bin