kern/152796: fcntl(2) audit records should not be labeled "file attribute modify"

jhell jhell at
Fri Dec 3 04:40:11 UTC 2010

The following reply was made to PR kern/152796; it has been noted by GNATS.

From: jhell <jhell at>
To: Garrett Wollman <wollman at>
Cc: FreeBSD-gnats-submit at
Subject: Re: kern/152796: fcntl(2) audit records should not be labeled "file
 attribute modify"
Date: Thu, 02 Dec 2010 23:06:29 -0500

 Hash: SHA1
 On 12/02/2010 18:43, Garrett Wollman wrote:
 >> Number:         152796
 >> Category:       kern
 >> Synopsis:       fcntl(2) audit records should not be labeled "file attribute modify"
 >> Confidential:   no
 >> Severity:       non-critical
 >> Priority:       low
 >> Responsible:    freebsd-bugs
 >> State:          open
 >> Quarter:        
 >> Keywords:       
 >> Date-Required:
 >> Class:          sw-bug
 >> Submitter-Id:   current-users
 >> Arrival-Date:   Fri Dec 03 00:10:11 UTC 2010
 >> Closed-Date:
 >> Last-Modified:
 >> Originator:     Garrett Wollman
 >> Release:        FreeBSD 8.1-RELEASE-p2 amd64
 >> Organization:
 > MIT Computer Science & Artificial Intelligence Lab
 >> Environment:
 > 8.1 system with auditing turned on
 >> Description:
 > 	/etc/security/audit_class describes class 0x8 as "file
 > attribute modify".  This seems like a reasonable thing to audit, but
 > unfortunately, all calls to fcntl(2) -- which does not modify any file
 > attributes -- are included in this category.  Any program which uses
 > POSIX-style locking will flood the audit file with spurious audit
 > records, while the interesting system calls (those that call
 > VOP_SETATTR) will be buried.  (And for whatever reason, auditreduce(1)
 > deosn't appear to perform as advertised when given the "-v" flag.)
 >> How-To-Repeat:
 > 	Enable auditing with class "fm".  praudit /var/audit/current.
 > Hit ^C when all you see is "fcntl(2)".
 >> Fix:
 > 	Move fcntl to a different audit class (probably "other" or
 > maybe "ioctl").
 To give a little background with this issue, I had addressed once with
 > On Sat, 6 Feb 2010 11:15, sson@ wrote:
 >> On Feb 6, 2010, at 6:48 AM, Robert N. M. Watson wrote:
 >>> On 5 Feb 2010, at 05:28, jhell wrote:
 >>>> I just wanted to run this by you quick informally before I
 >>>> approach any work on audit and changing things around that will
 >>>> never get changed possibly due to strict standards.
 >>>> I was setting up audit on a stable/7 remote booting X machine
 >>>> and wanted to audit any chmod's chflags etc... after final
 >>>> configuration I noticed that fcntl(2) is also included in the
 >>>> "fm" class but had noticed that ioctl(2) has its own class
 >>>> "io".
 >>>> So in my case on a Xserver I get high amounts of fcntl(2)
 >>>> changes logged. I would say at a guess of at the very least
 >>>> 1000 every 5 seconds. The machines these modifications are
 >>>> intended to be placed across are up constantly all week long.
 >>>> Being that these are file descriptors do you think it would
 >>>> possible to change them around and give fcntl(2) its own class
 >>>> "ds" or something similar ?
 >>>> What do you think would be the best way to approach this matter
 >>>> to bring fcntl(2) into its own class ?.
 >>> Well, I'd be a little worried about using up too many bits, the
 >>> class mask size is fixed in the ABI and difficult to expand.
 >>> Perhaps what we should do is move to a group named 'ct' or
 >>> something to reflect control calls, and put both fcntl and ioctl
 >>> in that? Christian and Stacey added the CC line as they may have
 >>> thoughts on this as well. One problem with ioctl, of course, is
 >>> that some ioctls are queries on pending bytes to sockets and
 >>> ttys, and others are administrative commands :-).
 > I agree moving these to something like "ct" would be considerably an
 > advantage over the current state that they are in. I'm starting to
 > find that the more I delve into this the more twists and turns I am
 > coming across as you have pointed out the limits on the mask size
 > etc. :(
 > What this is starting to make me think about is a way that the admin
 > could control certain aspects of audit. Something like the
 > audit_control file but only to turn off certain events either
 > specified by field 1 or 2 in audit_events and then by user or group.
 > Example idea below.
 #           (none)  Record both successful and failed events.
 #           +       Record successful events.
 #           -       Record failed events.
 #           ^       Record neither successful nor failed events.
 #           ^+      Do not record successful events.
 #           ^-      Do not record failed events.
 > # Field 1 event number, field 2 group spec, field 3 user spec # I put
 > them in this order since the effect of adding groups # could allow
 > the user field to be omitted entirely if the admin # has no users
 > he/she wants to specify.
 > # Do not audit fcntl events for group xusers except the user macguy. 
 > 30:^xusers:macguy
 > # No FIPS for Stacey! ;)
 > 65535::^stacey
 > Just a thought. I am sure that there is something that would really
 > effect this functionality and concern for security having a on-disk
 > way to exempt certain aspects of auditing but then again audit_users
 > already does that on a wider range of audit_events on the class
 > itself.
 > This could offer the fine grained control that some areas might just
 > be looking for.
 >> Yes, it is odd that ioctl has a class all to itself.  Of course,
 >> how ioctl is used has changed a lot from what it was originally
 >> intended for.  I suspect that ioctl was put in its own class for
 >> this very reason.  The overuse of the ioctl(2) interface has made
 >> it a target for bugs and potential security issues.  I recall that
 >> phk@ gave a talk on ioctl and making this argument as well some
 >> years back at BSDCan.
 >> WRT putting fcntl(2) in its own class I would agree with Robert.
 >> It would better if fcntl() events were moved into another class
 >> rather than creating a new one given the limited class mask size.
 >> Moving both ioctl and fcntl into a new class like "ct" seems like
 >> the right approach.
 > Seconded.
 >> On a similar subject I am thinking about adding an AUE_FIPS_AUDIT
 >> event as part of FIPS 140-2 (potential) compliance of FreeBSD.  I
 >> noticed that the mozilla nss security policy recommends that a new
 >> audit class be created (incorrectly): see
 >> I think it might be best if it was just simply added to the "ad"
 >> class. Do you see any problem with this?
 > Thanks for the information, I knew this was out there somewhere just
 > had not seen too many free man hours to go looking for it yet.  Bring
 > on the FIPS compliance!.  As for adding it to the :ad class I really
 > can't offer a real opinion on that other than it seems like the right
 > approach at this time.
 > This class mask size limitation is rather frustrating.
 - -- 

More information about the freebsd-bugs mailing list