On Wed, Jan 06, 2010 at 11:51:19AM -0800, Gary Winiger wrote: > For some reason, this never made it to the case log or my inbox. > Sorry for the delay. > > > From: Richard L. Hamilton <rlhamil at smart.net> > > To: opensolaris-arc at opensolaris.org > > Subject: Re: User object audit token [PSARC/2010/001 FastTrack timeout > > 01/11/2010] > > Date: Sat, 02 Jan 2010 05:39:59 -0800 (PST) > > > > Is the user SID also in audit output? If it isn't, shouldn't it be, if > > available, esp. > > if the UID is ephemeral? Wouldn't it be worth recording for forensics? > > The short answer is no presuming SIDs are Windows Security IDs > as opposed to Solaris Audit Session IDs. > > Windows SIDs are not presently part of OpenSolaris. Auditing > covers identified and authenticated users logged into OpenSolaris. > No OpenSolaris user has an ephemeral user ID. The purpose of
Well, I think you're splitting hairs. SIDs are definitely part of OpenSolaris, in ZFS, cred_t, the SMB stack, and the NFSv4 stack even, as well as libsec consumers like chmod(1) and ls(1). True, SIDs are represented as UIDs and GIDs -- ephemeral ones when no mapping to a real Unix user/group can be found -- in all places where there's no choice but to use UIDs/GIDs (or where there are standard interfaces that use UIDs/GIDs). But that's not the same thing as "SIDs are not ... part of OpenSolaris". > the user object token is to represent a user as the object > of some action, not as the subject of an action. In particular, > as noted in the case "passwd -f" auditing would be served well > by being able to express the user as an object in a searchable > way. Thus, the motivation for this new token. Indeed, this case is not about the subject of an audit record, but about an object that a an audit record is about. In this case there's no need for SIDs because the relevant admin interfaces currently can't be used to admin non-Unix Windows users/groups. Nico --
