On 9/19/19 1:19 PM, Ted Toth wrote:
On Thu, Sep 19, 2019 at 12:03 PM Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:
On 9/19/19 9:02 AM, Ted Toth wrote:
On Wed, Sep 18, 2019 at 9:18 AM Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:
On 9/18/19 10:03 AM, Ted Toth wrote:
On Wed, Sep 18, 2019 at 8:53 AM Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:
On 9/18/19 9:35 AM, Ted Toth wrote:
I'm seeing things like tclass=context#012 in some AVCs what is this telling me?
Just a guess here, but octal 012 is '\n' aka a newline character, and
libselinux/src/avc.c:avc_audit() appends a "\n" at the end of the buffer
before calling avc_log() to log the entire string. avc_log() will call
the logging callback, and dbusd does define one, which calls
audit_log_user_avc_message(). Maybe audit_log_user_avc_message() is
escaping the newline character in its output as well as appending
additional data.
I'm a little unclear though on why dbusd is checking a context contains
permission?
These appear to only occur when systemd is starting the dbus daemon
and they end up in /var/log/messages not /var/log/audit/audit.log as
I'd expect.
Sounds like auditd isn't operational at that point and therefore the
output just goes to syslog.
Arguably avc_audit() shouldn't be adding a newline at all and that
should be handled by the logging callback (or default_selinux_log if no
callback is set). But it has been this way forever, so that would no
doubt break some users. Legacy of when this was a printk/printf.
FWIW here's the comments from the function dbus uses that calls
avs_has_perm where the contains check happens. Why dbus policy does
not allow this is seems like an oversight.
dbusd doesn't check context contains permission AFAIK, only acquire_svc
and send_msg permissions in the dbus class. Is that something you
added? Or are we picking up some kind of pam module interaction?
You're right it only checks those permissions not contains :( We don't
modify dbus.
How were you thinking pam could be involved?
No idea but pam_selinux does check context contains permission. If
dbusd is firing off anything that has pam_selinux in its pam stack,
maybe that would show up? I don't know.
Other scenario is that the check isn't truly for context contains but
rather is a class/permission mapping problem, e.g. your dbusd isn't
using selinux_set_mapping() or equivalent to map its class/perms and
your policy has the context contains definitions where it expects the
dbus class/perms to be.
/**
* Determine if the SELinux security policy allows the given sender
* security context to go to the given recipient security context.
* This function determines if the requested permissions are to be
* granted from the connection to the message bus or to another
* optionally supplied security identifier (e.g. for a service
* context). Currently these permissions are either send_msg or
* acquire_svc in the dbus class.
*
* @param sender_sid source security context
* @param override_sid is the target security context. If SECSID_WILD this will
* use the context of the bus itself (e.g. the default).
* @param target_class is the target security class.
* @param requested is the requested permissions.
* @returns #TRUE if security policy allows the send.
*/
#ifdef HAVE_SELINUX
static dbus_bool_t
bus_selinux_check (BusSELinuxID *sender_sid,
BusSELinuxID *override_sid,
security_class_t target_class,
access_vector_t requested,
DBusString *auxdata)
