From: Stephen Smalley <sds@tycho.nsa.gov>
To: Ted Toth <txtoth@gmail.com>
Cc: selinux@vger.kernel.org
Subject: Re: strange tclass in AVCs
Date: Thu, 19 Sep 2019 13:24:50 -0400 [thread overview]
Message-ID: <2d8a08ba-785d-bccc-69a7-e3de38a16f64@tycho.nsa.gov> (raw)
In-Reply-To: <CAFPpqQG_2B=-E8HNEaMkkKidXWPSuEs9M_ZWR7u_YdQ7KmvuCQ@mail.gmail.com>
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)
>>>
>>
prev parent reply other threads:[~2019-09-19 17:27 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-18 13:35 strange tclass in AVCs Ted Toth
2019-09-18 13:46 ` Dominick Grift
2019-09-18 13:49 ` Dominick Grift
2019-09-18 13:51 ` Ted Toth
2019-09-18 13:53 ` Stephen Smalley
2019-09-18 14:03 ` Ted Toth
2019-09-18 14:11 ` Ted Toth
2019-09-18 14:17 ` Stephen Smalley
2019-09-19 13:02 ` Ted Toth
2019-09-19 17:03 ` Stephen Smalley
2019-09-19 17:19 ` Ted Toth
2019-09-19 17:24 ` Stephen Smalley [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2d8a08ba-785d-bccc-69a7-e3de38a16f64@tycho.nsa.gov \
--to=sds@tycho.nsa.gov \
--cc=selinux@vger.kernel.org \
--cc=txtoth@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).