From: Dominick Grift <dac.override@gmail.com>
To: Russell Coker <russell@coker.com.au>
Cc: "Sugar, David" <dsugar@tresys.com>,
"selinux-refpolicy@vger.kernel.org"
<selinux-refpolicy@vger.kernel.org>
Subject: Re: [PATCH 3/3] Some items that seem they can be dontaudited for plymouthd
Date: Sat, 13 Apr 2019 09:54:48 +0200 [thread overview]
Message-ID: <20190413075448.GB5901@brutus.lan> (raw)
In-Reply-To: <14839769.DdiKdgLD4o@xev>
[-- Attachment #1: Type: text/plain, Size: 1603 bytes --]
On Sat, Apr 13, 2019 at 02:24:25PM +1000, Russell Coker wrote:
> On Saturday, 13 April 2019 1:26:06 PM AEST Sugar, David wrote:
> > On 4/12/19 10:33 PM, Russell Coker wrote:
> > > What is netlink_kobject_uevent_socket? Do we have a place we can document
> > > this sort of thing to make it easier to determine whether access is
> > > required and what the implications of such access are?
> >
> > I'm really not sure either. But, please note, that this patch is
> > dontaudit rules to quiet some denials that didn't seem to have any
> > negative side effect. If this patch isn't applied things will still
> > function, just have some entries in the audit logs.
>
> There's a good chance the action in question isn't an accident and some aspect
> of the program's functionality will be changed. I think it's best to have an
> idea of what the issue was before putting in a dontaudit rule, if some
> configuration of that program actually needs such functionality then a
> dontaudit will make it inconvenient to track it down.
>
> Have you tried running strace or ltrace to see what it's doing?
I agree that this probably shouldnt be dontaudited. This is a common pattern for "udev clients"
The kobject_uevent socket aspect is probably to monitor devices (equivalent to `udevadm monitor`)
>
> --
> My Main Blog http://etbe.coker.com.au/
> My Documents Blog http://doc.coker.com.au/
>
--
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 --]
next prev parent reply other threads:[~2019-04-13 7:54 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-12 19:39 [PATCH 0/3] Resolve issues with plymouth in enforcing Sugar, David
2019-04-12 19:39 ` [PATCH 1/3] Allow xdm (lightdm) execute plymouth Sugar, David
2019-04-17 2:49 ` Sugar, David
2019-04-23 22:31 ` Chris PeBenito
2019-04-12 19:39 ` [PATCH 2/3] Changes to support plymouth working in enforcing Sugar, David
2019-04-13 2:43 ` Russell Coker
2019-04-13 3:23 ` Sugar, David
2019-04-13 4:24 ` Russell Coker
2019-04-13 7:51 ` Dominick Grift
2019-04-17 2:51 ` Sugar, David
2019-04-23 22:31 ` Chris PeBenito
2019-04-12 19:39 ` [PATCH 3/3] Some items that seem they can be dontaudited for plymouthd Sugar, David
2019-04-13 2:33 ` Russell Coker
2019-04-13 3:26 ` Sugar, David
2019-04-13 4:24 ` Russell Coker
2019-04-13 7:54 ` Dominick Grift [this message]
2019-04-17 2:53 ` Sugar, David
2019-04-14 17:49 ` Chris PeBenito
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=20190413075448.GB5901@brutus.lan \
--to=dac.override@gmail.com \
--cc=dsugar@tresys.com \
--cc=russell@coker.com.au \
--cc=selinux-refpolicy@vger.kernel.org \
/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).