MCKEEVER@UMKCVAX2.BITNET (06/24/87)
Hobbit at Rutgers Writes... <Turning on "authorization" security audits will not catch people using <the hole. Since the hole involves directly $GETting and $PUTting your <own records, it completely bypasses the call to the audit mechanism in <$setuai, thus you lose. A proper ACL, however, may inform you when someone <opens the file for write... < <_H* I was afraid that would happen. I had a faint hope though that this would not be the case. His ACL idea sounds sound. (Sounds sound??) Oh well, I'm not an English major. Thanks for the information Hobbit. And tell Bilbo I said Hi... ;-) Phil Wherry from the MITRE Corporation writes that I left something out of the my recommendation for the audit alarm... It should have been: $ SET AUDIT/ALARM/ENABLE=(AUTH, ACL, AUDIT) In this way, all auditing changes will be logged, including turning off audit alarms. Phil also points out that someone with priv's could shut down OPCOM or keep it from coming up at all. That's true. The main thrust of my submission was to catch non-priv hackers. I assumed that the type of priv's needed to get around this would not be granted to individuals that couldn't be trusted. And if you give any of the ALL class of priv's (CMKRNL, SYSPRV, BYPASS, READALL, SYSNAM,...) to someone, they can own your system in a number of ways that are all a lot easier to do than trying to take advantage of the security hole. But Phil makes a valid point. Thanks. Thanks to all that responded. ------------------------------------------------------------------------- UMU UMUMUMUMUM UMU UMUMUMUMUM Brian McKeever UMU UMUMUMUMUM UMU UMUMUMUMUM University of Missouri Kansas City U UM U Computer Science U UM UM UM 4747 Building Rm. 219 UMUMUMUM UMUM UMUM 5100 RockHill Rd. UMUMUMUM UMUM UMUM Kansas City, MO 64110 UMUMUMUM UMUM UMUM BITNET: MCKEEVER@UMKCVAX1 UMUMUMUM UMUM UMUM -------------------------------------------------------------------------