[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

proposed interface changes for filesystem audit



Hello,

The current approach to filesystem auditing requires some changes to
the kernel-userspace interface.  We've discussed these in various
conversations on IRC, but Steve asked me to summarize the changes here
so we can review them collectively.

Comments appreciated.

Thanks,
Amy


Kernel-Userspace Interface Changes
----------------------------------
Following are the proposed changes to the kernel-userspace interface:

(1) A new version of struct audit_rule that supports string fields.

    struct audit_rule_xprt {
        uint32_t                flags;
        uint32_t                action;
        uint32_t                field_count;
        uint32_t                mask[AUDIT_BITMASK_SIZE];
        uint32_t                fields[AUDIT_MAX_FIELDS];
        uint32_t                values[AUDIT_MAX_FIELDS];
        uint32_t                buflen;
        char                    buf[0];
    };

    This struct adds two fields, buf and buflen, to the fields
    currently defined in struct audit_rule.  The field buf is a
    variable length string that could potentially hold any number of
    null-delimited string fields.  When defining a string field, the
    fields[] element specifies the field type and the values[] element
    specifies the length of the string field.  String fields in the
    buffer are processed in the order in which they occur in the
    fields[],values[] arrays.

    In the case of filesystem watches, the string path is converted to
    an inode number for use in the actual filter.  If we decide to
    support other string fields in filters, the performance impact of
    doing a strcmp() should be understood.

(2) New netlink message types for adding, removing and listing rules
    with a string field, i.e.:  

    AUDIT_ADD_RULE
    AUDIT_DEL_RULE
    AUDIT_LIST_RULES

    When the kernel receives a message type of AUDIT_ADD, AUDIT_DEL,
    or AUDIT_LIST, it will interpret the data using the older
    audit_rule struct.
    
(3) A new rule field type, i.e.:

    AUDIT_PATHNAME
    
(4) To accommodate these changes, libaudit must provide new routines
    for adding, removing and listing rules using the new struct and
    message types, i.e.:

    extern int  audit_req_rules_buf(int fd);
    extern int  audit_add_rule_buf(int fd, struct audit_rule_xprt *rule);
    extern int  audit_del_rule_buf(int fd, struct audit_rule_xprt *rule);

(5) Libaudit must add struct audit_rule_xprt to the union in
    struct audit_reply.


Command Line Changes
--------------------
The following changes would be necessary for the auditctl command to
support the proposed changes to the kernel-userspace interface:

(1) A new field allowed for the -F option, i.e.:

    -F path=/home/watchme

    Additionally, the inode and path fields should not be specified in
    the same rule, as the inode field would be ignored.

(2) A set of filesystem-related aliases for groups of system calls.
    Currently, one alias "all" is provided that maps to the full set
    of system calls on a given arch.

    Here are some examples of other aliases that could be provided:

    fs-create:  creat,link,mkdir,mknod,open,rename,symlink
    fs-remove:  rename,rmdir,unlink
    fs-attr:    chmod,chown,fchmod,fchown,fremovexattr,fsetxattr,lchown,
                lremovexattr,lsetxattr,removexattr,setxattr,truncate,utime(s)
    fs-all:     all filesystem-related syscalls

(3) If backward compatibility with the -w,-W, and -p options is
    desired, auditctl could be modified to populate an audit_rule_xprt
    struct with the provided path string and a set of syscalls that
    maps to the previous behavior.  For example, "-p w" would map to
    the syscalls specified by the fs-create, fs-remove and fs-attr
    aliases above, while -w by itself would map to the fs-all alias.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]