Date: Tue, 21 Sep 1999 07:08:08 -0700 From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> To: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> Cc: imp@village.org (Warner Losh), wes@softweyr.com (Wes Peters), brett@lariat.org (Brett Glass), security@FreeBSD.ORG Subject: Auditing (was Re: BPF on in 3.3-RC GENERIC kernel) Message-ID: <199909211409.HAA06629@cwsys.cwsent.com> In-Reply-To: Your message of "Fri, 17 Sep 1999 23:24:07 PDT." <199909180624.XAA50611@gndrsh.dnsmgr.net>
index | next in thread | previous in thread | raw e-mail
In message <199909180624.XAA50611@gndrsh.dnsmgr.net>, "Rodney W.
Grimes" writes
:
> > In message <37E32365.B9F9573B@softweyr.com> Wes Peters writes:
> > : Worked for me. A well-written, accurate analogy too.
> >
> > I'll have to try again later... I'd be very interested in this. I
> > personally think that schg is useful against accidental mistakes, but
> > flawed in implementation.
> >
> > Although some of that may be due to inperfections in /etc/rc and
> > friends.
>
> Once you read the article you will see just how flawed ``schg'' is. It
> only attempts to prevent action, it does not send out any alarms.
>
> The propasal that jdp has on a socket sort of notification facility for
> all file system modifications is a long was ahead of what could ever
> be done with schg, as that tool would give us the ability to real time
> audit even attempts at cracking on the system. ACF2 in the mainframe
> world, and the VMS AUDIT tools are good examples of what can be done
> with this type of feature. Real time alarms if someone even _tries_
> to modify a schg file is what is missing... someone turning off
> schg on a file is another thing missing... or accessing the disk
> through the raw device to reset the bit, etc, etc...
If I may add, in my former life we even monitored the actions users
were allowed to do, e.g. delete their own files, on MVS systems using
RACF, ACF2 or or even turned on the SMF facility to monitor which files
were created, opened, deleted, etc. The reason for this had less to do
with security and more to do with users complaining "my file just
disappeared" and proving that they or a person who borrowed their
account [bad idea] were the ones who had actually removed a file.
The other things we did (at one shop with RACF) were to audit all
actions performed by any accounts with the operations (read/write any
object) or RACF special (alter the security profile of any object)
flags set; and audit all actions performed against files defined as APF
authorized (security sensitive) libraries -- APF authorization is
loosely akin to setuid root, though the analogy easily breaks.
Finally the people doing the auditing, security administration, and
operations could not have all three attributes assigned to their
accounts. According to an IBM course I too approximately 20 years ago,
each of the auditor, operations, and security staff would watch each
other. The reason IBM gave for this separation was that it was harder
for three persons to conspire to undermine security than it was for two
to do so.
Regards, Phone: (250)387-8437
Cy Schubert Fax: (250)387-5766
Open Systems Group Internet: Cy.Schubert@uumail.gov.bc.ca
ITSD Cy.Schubert@gems8.gov.bc.ca
Province of BC
"e**(i*pi)+1=0"
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909211409.HAA06629>