selinux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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:03:54 -0400	[thread overview]
Message-ID: <e8f03fe4-9a6d-3803-9766-ab3226fe79ed@tycho.nsa.gov> (raw)
In-Reply-To: <CAFPpqQHJU8sta7t5ZQ2PQCJi064Po4jXZ2g-LAoOZPF9rtd-pQ@mail.gmail.com>

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


  reply	other threads:[~2019-09-19 17:03 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 [this message]
2019-09-19 17:19           ` Ted Toth
2019-09-19 17:24             ` Stephen Smalley

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=e8f03fe4-9a6d-3803-9766-ab3226fe79ed@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).