|
|
| Author |
Message |
scg
|
|
Security on a Mac network
| 
Dec 12 20:11 UTC 1994 |
We've got AppleShare running on our Mac network at school, as well
as running FileGuard, and the two don't seem to be compatable. When
something is protected with FileGuard on one machine, and is shared into
from another machine, nothing is protected. My original reaction when I
found the problem was to keep make sharing not work without a password, so
that those of us on the computing staff would still be able to use sharing
to move things around, but students in general could not use it.
unfortunately, my attempts to protect the sharing control pannel from being
changed were unsuccessful, and I realized today how much of a problem this
is, when I tried to share from a computer and found that the password
didn't work on it. Less than a minute later, I was approached by a couple
of people bragging about having gotten around the security. I went over
and looked, and it turned out that not only had they changed the password
for sharing on the machine, but they had then exploited their newfound
access to wipe out absolutely everything on the hard drive.
My question, therefore, is whether there is a way to make
AppleShare and FileGuard work together, or, if not, whether there is
another package that will do both sharing and security.
|
| 9 responses total. |
hawkeye
|
|
response 1 of 9:
|
Dec 13 14:49 UTC 1994 |
There are a couple of ways to look at this:
1) Assume that there's little you can do about it and just reformat and
reload the hard disks occasionally. The labs at CAEN do this -- they
assume that people will mess things up frequently enough that they run
a "reload" program often enough. Once the initial novelty of the network
is gone, people will -- in general -- respect it.
2) You could *try* to make the "Sharing Setup" control panel invisible
and see if it still works. This is something I haven't tried, but I would
imagine that it would still be O.K.
In my experience from running a network, there are a number of specific
types of people to deal with: (1) those who will leave well enough alone
and not mess with what you set up, (2) those who will modify what you set up
because they either think they are being clever or they are doing something
"bad" -- like pirating software, (3) those who modify things because they
don't feel you've address security issues enough to satisfy them and (4)
those who wouldn't know what you did if you spelled it out to them.
1 and 4 are easy to deal with as they won't touch anything. 3 you can
work with to explain how it works and just have them inform you if they
change the password. People who fall in the 2 category are pains in the butt.
Hopefully, you won't have many of them to deal with.
|
matts
|
|
response 2 of 9:
|
Dec 22 22:23 UTC 1994 |
being in the "business", I can tell you that Macintosh and Security
are together a very obvious oxy-moron.
|
rcurl
|
|
response 3 of 9:
|
Mar 17 18:04 UTC 2000 |
If that is the case, how does on bypass Disklock on a Mac? A Mac was left
in my wife's new UM lab, so they thought they could use it. However, it
has Disklock enabled. So, if "Macintosh and Security are together a very
obvious oxy-moron", it should be a snap to unlock it, right?
|
gull
|
|
response 4 of 9:
|
Mar 18 07:17 UTC 2000 |
Here at Tech, they use RevRDist to keep the hard disks in line, generally.
(Though it's slow enough that often people cancel it instead of letting it
run.) Some control panels are made unusable for students by the simple
trick of placing them on the administration server, which can only be
mounted by staff. I believe they put aliases of the control panels in the
control panel folder, so when the server is mounted, everything in the
Control Panel works normally. Obviously there's a problem with doing this
with the sharing control panel, though, since you'll have a chicken-and-egg
problem.
No machine on which people have console access is ever *totally* secure.
(This goes double for Linux and most other UNIXes; they're trivially easy to
break into from the console, unless the machine has a hardware password.)
However, I've seen some Mac setups that were pretty secure. The trick is
that it's easy to lock down a machine with FileGuard to the point where it's
completely useless. At Alma College, on some machines, if your data floppy
was full you were SOL, since you couldn't drag anything to the trash. This
kind of extreme only encourages people to try to break the security, either
for the challenge or simply so they can get work done. MTU generally just
uses RevRDist and otherwise trusts people not to screw things up, and that
normally works fine here.
The quickest way around FileGuard seems to be to boot off a System floppy.
If your machines are networked and students don't have to shlep files around
on floppies, a floppy drive lock or simply removing the drive will eliminate
this problem entirely.
|
n8nxf
|
|
response 5 of 9:
|
Mar 20 12:30 UTC 2000 |
I have brought two PowerBooks back from the "dead". They both had FileGuard
on them and would ask for password, etc. even when boot off a floppy. I
removed the HD and reattached it after the machine started to boot off the
floppy. That way the HD wouldn't be mounted by the system and I could use
a formatting utility to format the HD before it was remounted. All data gone
but the machines were usable again without buying a new HD. FileGuard is
dang good!
|
rcurl
|
|
response 6 of 9:
|
Mar 20 17:15 UTC 2000 |
I presume the same procedure would work against Disklock. Did you just
plug the HD back in "hot" while rebooting?
|
gull
|
|
response 7 of 9:
|
Mar 20 17:59 UTC 2000 |
Nah, I booted off a System 6 floppy and it mounted the HD normally. Disk
Lock may do tricky things to keep a "foreign" System from mounting the hard
drive, though. I think that's possible on a Mac.
|
rcurl
|
|
response 8 of 9:
|
Mar 20 20:53 UTC 2000 |
Yes, a system on a floppy does not defeat Diskloack. But I was asking
Klaus how he did the HD substitution.
|
n8nxf
|
|
response 9 of 9:
|
Mar 21 12:09 UTC 2000 |
Yep, I did it hot. You just have to be very careful to have all the pins
lined up correctly, as you can guess.
|