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? > > > > > /** > > * 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) > > >
