* strange tclass in AVCs @ 2019-09-18 13:35 Ted Toth 2019-09-18 13:46 ` Dominick Grift 2019-09-18 13:53 ` Stephen Smalley 0 siblings, 2 replies; 12+ messages in thread From: Ted Toth @ 2019-09-18 13:35 UTC (permalink / raw) To: selinux [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: strange tclass in AVCs 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:53 ` Stephen Smalley 1 sibling, 1 reply; 12+ messages in thread From: Dominick Grift @ 2019-09-18 13:46 UTC (permalink / raw) To: Ted Toth; +Cc: selinux [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: strange tclass in AVCs 2019-09-18 13:46 ` Dominick Grift @ 2019-09-18 13:49 ` Dominick Grift 2019-09-18 13:51 ` Ted Toth 0 siblings, 1 reply; 12+ messages in thread From: Dominick Grift @ 2019-09-18 13:49 UTC (permalink / raw) To: Ted Toth, selinux [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: strange tclass in AVCs 2019-09-18 13:49 ` Dominick Grift @ 2019-09-18 13:51 ` Ted Toth 0 siblings, 0 replies; 12+ messages in thread From: Ted Toth @ 2019-09-18 13:51 UTC (permalink / raw) To: Dominick Grift; +Cc: selinux 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: strange tclass in AVCs 2019-09-18 13:35 strange tclass in AVCs Ted Toth 2019-09-18 13:46 ` Dominick Grift @ 2019-09-18 13:53 ` Stephen Smalley 2019-09-18 14:03 ` Ted Toth 1 sibling, 1 reply; 12+ messages in thread From: Stephen Smalley @ 2019-09-18 13:53 UTC (permalink / raw) To: Ted Toth, selinux 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? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: strange tclass in AVCs 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 0 siblings, 2 replies; 12+ messages in thread From: Ted Toth @ 2019-09-18 14:03 UTC (permalink / raw) To: Stephen Smalley; +Cc: selinux 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: strange tclass in AVCs 2019-09-18 14:03 ` Ted Toth @ 2019-09-18 14:11 ` Ted Toth 2019-09-18 14:17 ` Stephen Smalley 1 sibling, 0 replies; 12+ messages in thread From: Ted Toth @ 2019-09-18 14:11 UTC (permalink / raw) To: Stephen Smalley; +Cc: selinux 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: strange tclass in AVCs 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 1 sibling, 1 reply; 12+ messages in thread From: Stephen Smalley @ 2019-09-18 14:17 UTC (permalink / raw) To: Ted Toth; +Cc: selinux 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: strange tclass in AVCs 2019-09-18 14:17 ` Stephen Smalley @ 2019-09-19 13:02 ` Ted Toth 2019-09-19 17:03 ` Stephen Smalley 0 siblings, 1 reply; 12+ messages in thread From: Ted Toth @ 2019-09-19 13:02 UTC (permalink / raw) To: Stephen Smalley; +Cc: selinux 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) ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: strange tclass in AVCs 2019-09-19 13:02 ` Ted Toth @ 2019-09-19 17:03 ` Stephen Smalley 2019-09-19 17:19 ` Ted Toth 0 siblings, 1 reply; 12+ messages in thread From: Stephen Smalley @ 2019-09-19 17:03 UTC (permalink / raw) To: Ted Toth; +Cc: selinux 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) > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: strange tclass in AVCs 2019-09-19 17:03 ` Stephen Smalley @ 2019-09-19 17:19 ` Ted Toth 2019-09-19 17:24 ` Stephen Smalley 0 siblings, 1 reply; 12+ messages in thread From: Ted Toth @ 2019-09-19 17:19 UTC (permalink / raw) To: Stephen Smalley; +Cc: selinux 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) > > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: strange tclass in AVCs 2019-09-19 17:19 ` Ted Toth @ 2019-09-19 17:24 ` Stephen Smalley 0 siblings, 0 replies; 12+ messages in thread From: Stephen Smalley @ 2019-09-19 17:24 UTC (permalink / raw) To: Ted Toth; +Cc: selinux 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) >>> >> ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2019-09-19 17:27 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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).