strange tclass in AVCs

strange tclass in AVCs

[Ted Toth]

[-- Attachment #1: Type: text/plain, Size: 85 bytes --]

I'm seeing things like tclass=context#012 in some AVCs what is this telling me?

Ted

[-- Attachment #2: Screen Shot 2019-09-18 at 8.33.16 AM.png --]
[-- Type: image/png, Size: 35063 bytes --]

Re: strange tclass in AVCs

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 385 bytes --]

On Wed, Sep 18, 2019 at 08:35:09AM -0500, Ted Toth wrote:
> I'm seeing things like tclass=context#012 in some AVCs what is this telling me?

https://selinuxproject.org/page/ObjectClassesPerms#context

> 
> Ted



-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: strange tclass in AVCs

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 703 bytes --]

On Wed, Sep 18, 2019 at 03:46:42PM +0200, Dominick Grift wrote:
> On Wed, Sep 18, 2019 at 08:35:09AM -0500, Ted Toth wrote:
> > I'm seeing things like tclass=context#012 in some AVCs what is this telling me?
> 
> https://selinuxproject.org/page/ObjectClassesPerms#context

Not sure what the #012 suffix is doing there though

> 
> > 
> > Ted
> 
> 
> 
> -- 
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift



-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: strange tclass in AVCs

[Ted Toth]

On Wed, Sep 18, 2019 at 8:49 AM Dominick Grift <dac.override@gmail.com> wrote:
>
> On Wed, Sep 18, 2019 at 03:46:42PM +0200, Dominick Grift wrote:
> > On Wed, Sep 18, 2019 at 08:35:09AM -0500, Ted Toth wrote:
> > > I'm seeing things like tclass=context#012 in some AVCs what is this telling me?
> >
> > https://selinuxproject.org/page/ObjectClassesPerms#context
>
> Not sure what the #012 suffix is doing there though

That's the crux of my question ;)

>
> >
> > >
> > > Ted
> >
> >
> >
> > --
> > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> > https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> > Dominick Grift
>
>
>
> --
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift

Re: strange tclass in AVCs

[Stephen Smalley]

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?

Re: strange tclass in AVCs

[Ted Toth]

On Wed, Sep 18, 2019 at 8:53 AM Stephen Smalley <sds@tycho.nsa.gov> 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.

Re: strange tclass in AVCs

[Ted Toth]

On Wed, Sep 18, 2019 at 9:03 AM Ted Toth <txtoth@gmail.com> wrote:
>
> On Wed, Sep 18, 2019 at 8:53 AM Stephen Smalley <sds@tycho.nsa.gov> 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.

Maybe audit isn't up yet.

Re: strange tclass in AVCs

[Stephen Smalley]

On 9/18/19 10:03 AM, Ted Toth wrote:
> On Wed, Sep 18, 2019 at 8:53 AM Stephen Smalley <sds@tycho.nsa.gov> 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.

Re: strange tclass in AVCs

[Ted Toth]

On Wed, Sep 18, 2019 at 9:18 AM Stephen Smalley <sds@tycho.nsa.gov> wrote:
>
> On 9/18/19 10:03 AM, Ted Toth wrote:
> > On Wed, Sep 18, 2019 at 8:53 AM Stephen Smalley <sds@tycho.nsa.gov> 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.

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

Re: strange tclass in AVCs

[Stephen Smalley]

On 9/19/19 9:02 AM, Ted Toth wrote:
> On Wed, Sep 18, 2019 at 9:18 AM Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>
>> On 9/18/19 10:03 AM, Ted Toth wrote:
>>> On Wed, Sep 18, 2019 at 8:53 AM Stephen Smalley <sds@tycho.nsa.gov> 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?

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

Re: strange tclass in AVCs

[Ted Toth]

On Thu, Sep 19, 2019 at 12:03 PM Stephen Smalley <sds@tycho.nsa.gov> wrote:
>
> On 9/19/19 9:02 AM, Ted Toth wrote:
> > On Wed, Sep 18, 2019 at 9:18 AM Stephen Smalley <sds@tycho.nsa.gov> wrote:
> >>
> >> On 9/18/19 10:03 AM, Ted Toth wrote:
> >>> On Wed, Sep 18, 2019 at 8:53 AM Stephen Smalley <sds@tycho.nsa.gov> 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)
> >
>

Re: strange tclass in AVCs

[Stephen Smalley]

On 9/19/19 1:19 PM, Ted Toth wrote:
> On Thu, Sep 19, 2019 at 12:03 PM Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>
>> On 9/19/19 9:02 AM, Ted Toth wrote:
>>> On Wed, Sep 18, 2019 at 9:18 AM Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>>>
>>>> On 9/18/19 10:03 AM, Ted Toth wrote:
>>>>> On Wed, Sep 18, 2019 at 8:53 AM Stephen Smalley <sds@tycho.nsa.gov> 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)
>>>
>>