davism@creatures.cs.vt.edu (Mat Davis) (05/30/90)
In the fall, we plan to put A/UX 2.0 on ten lab machines and we'd like to allow users to run the Mac environment if they like. Has anyone experimented with viruses under 2.0? I'm hoping that if we set the machines up correctly A/UX will be able to prevent a virus from infecting them, but I don't have copies of any viruses to try. It seems as if the normal Unix protections should stop the viruses, but the Mac Toolbox appears to have at least *some* special privileges (such as being exempt from the "10% free" limit on ufs filesystems) and that leads me to wonder if that would weaken the protections. As a last resort, we *could* create a new, clean system folder each time the 'guest' user logs in, but that will slow the login process considerably. Mat
amanda@mermaid.intercon.com (Amanda Walker) (05/31/90)
In article <402@creatures.cs.vt.edu>, davism@creatures.cs.vt.edu (Mat Davis) writes: > As a last resort, we *could* create a new, clean system folder each time the > 'guest' user logs in, but that will slow the login process considerably. You could do it when the previous person logs off, which would move the time consumed to the relatively "invisible" period between users... -- Amanda Walker InterCon Systems Corporation
davism@creatures.cs.vt.edu (Mat Davis) (05/31/90)
In article <26640B70.A8A@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes: >In article <402@creatures.cs.vt.edu>, davism@creatures.cs.vt.edu (Mat Davis) >writes: >> As a last resort, we *could* create a new, clean system folder each time the >> 'guest' user logs in, but that will slow the login process considerably. > >You could do it when the previous person logs off, which would move the time >consumed to the relatively "invisible" period between users... The problem with cleaning out /users/guest when someone logs off is that people occasionally forget to copy files to diskette before logging out. By only deleting the files when 'guest' logs in, an operator can log in and save files if someone realizes that they have just logged out without saving them.
jk@Apple.COM (John Kullmann) (05/31/90)
In article <402@creatures.cs.vt.edu> davism@vtopus.cs.vt.edu (Mat Davis) writes: >In the fall, we plan to put A/UX 2.0 on ten lab machines and we'd like to >allow users to run the Mac environment if they like. Has anyone experimented >with viruses under 2.0? I'm hoping that if we set the machines up correctly >A/UX will be able to prevent a virus from infecting them, but I don't have >copies of any viruses to try. We use the Symantec virus checkers, they work under A/UX 2.0. -- John Kullmann jk@apple.com
liam@cs.qmw.ac.uk (Paul Davison (postmaster)) (05/31/90)
In <402@creatures.cs.vt.edu> davism@creatures.cs.vt.edu (Mat Davis) writes: >In the fall, we plan to put A/UX 2.0 on ten lab machines and we'd like to >allow users to run the Mac environment if they like. Has anyone experimented >with viruses under 2.0? I'm hoping that if we set the machines up correctly >A/UX will be able to prevent a virus from infecting them, but I don't have >copies of any viruses to try. I tried WDEF and nVIR B on an early A/UX 2.0 beta and neither of them were harmful: WDEF didn't do anything, nVIR could be persuaded to infect the System file but not to pass on the infection to other applications launched from A/UX filestores (we didn't try Mac floppies or HFS volumes). Expect viruses to work under A/UX before long - the compatibility is getting pretty good... :-) :-( ? >It seems as if the normal Unix protections should stop the viruses, but the >Mac Toolbox appears to have at least *some* special privileges (such as being >exempt from the "10% free" limit on ufs filesystems) and that leads me to >wonder if that would weaken the protections. This isn't true - the Macintosh emulation runs as you and doesn't subvert the normal A/UX permissions (as far as I can tell). It definitely doesn't sidestep the "minfree for root" aspect of BSD filesystems. >As a last resort, we *could* create a new, clean system folder each time the >'guest' user logs in, but that will slow the login process considerably. Won't help you, unless you have extra clean copies of the applications as well. We do however run a system which broadcasts complete disk images to our A/UX client machines (currently A/UX 1.1.1) which would at least give you a clean machine first thing in the morning. -- William Roberts ARPA: liam@cs.qmw.ac.uk Queen Mary & Westfield College UUCP: liam@qmw-cs.UUCP Mile End Road AppleLink: UK0087 LONDON, E1 4NS, UK Tel: 071-975 5250 (Fax: 081-980 6533)
davism@creatures.cs.vt.edu (Mat Davis) (06/01/90)
In article <2303@sequent.cs.qmw.ac.uk> liam@cs.qmw.ac.uk (Paul Davison (postmaster)) writes: >...the Macintosh emulation runs as you and >doesn't subvert the normal A/UX permissions (as far as I can >tell). It definitely doesn't sidestep the "minfree for root" >aspect of BSD filesystems. Oops..that comes from forgetting that I need to 'df' from root to find out how much space is *really* left; must've been early in the morning :-). >In <402@creatures.cs.vt.edu> davism@creatures.cs.vt.edu (Mat Davis) writes: > >>As a last resort, we *could* create a new, clean system folder each time the >>'guest' user logs in, but that will slow the login process considerably. > >Won't help you, unless you have extra clean copies of the >applications as well. We're planning to just provide the Mac system files and nothing else (no applications; the students will have to bring those in on diskette). So using symlinks to most of the system files and actual copies of Finder, System, LaserWriter, and so on shouldn't involve too much overhead. I'm considering modifying /mac/bin/mac32 so that *it* would do the copying when invoked, so that anyone logging in using just the console emulator won't have to wait for copying files that they won't use. Mat Davis (davism@vtopus.cs.vt.edu)