From: Paul Moore <paul@paul-moore.com>
To: Stephen Smalley <sds@tycho.nsa.gov>,
Guido Trentalancia <guido@trentalancia.net>
Cc: selinux@tycho.nsa.gov
Subject: Re: [PATCH v4] Classify AF_ALG sockets
Date: Tue, 23 Aug 2016 09:35:21 -0400 [thread overview]
Message-ID: <CAHC9VhQ08yOuosiApLSLCxoP73YSY=igrwJ7kO3qvR1uMwBJoQ@mail.gmail.com> (raw)
In-Reply-To: <9899189e-9352-fdff-2362-47fe1ca7e52b@tycho.nsa.gov>
On Tue, Aug 23, 2016 at 9:05 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On 08/22/2016 06:36 PM, Paul Moore wrote:
>> On Mon, Aug 22, 2016 at 5:04 PM, Guido Trentalancia
>> <guido@trentalancia.net> wrote:
>>> Modify the SELinux kernel code so that it is able to classify sockets with
>>> the new AF_ALG namespace (used for the user-space interface to the kernel
>>> Crypto API).
>>>
>>> A companion patch has been created for the Reference Policy and it will be
>>> posted to its mailing list, once this patch is merged.
>>>
>>> Signed-off-by: Guido Trentalancia <guido@trentalancia.net>
>>> ---
>>> security/selinux/hooks.c | 5 +++++
>>> security/selinux/include/classmap.h | 2 ++
>>> security/selinux/include/security.h | 2 ++
>>> security/selinux/ss/services.c | 3 +++
>>> 4 files changed, 12 insertions(+)
>>
>> You are still missing the policy capability code for
>> security/selinux/selinuxfs.c. I think it would also be a good idea to
>> write a test for this and add it to the selinux-testsuite; not only
>> will this help us confirm this code works as expected, but it will
>> demonstrate what the new policy would look like and help establish a
>> regression test for future use.
>>
>> * https://github.com/SELinuxProject/selinux-testsuite
>
> I also think that if we are going to go to the trouble of adding a new
> policy capability for this (versus just relying on
> handle_unknown=allow), then we ought to identify and define all socket
> classes that we think we might want. Otherwise we'll end up with 50
> different policy capabilities, one for each new socket class.
To be clear, we can't rely only on the new/unknown object class
handling for this particular case since this change would convert some
of the existing generic socket access checks to the algsocket access
checks which could result in undesired access for policies which set
handle_unknown=allow. The new/unknown object class handling works
well for new access controls, but sometimes has problems with modified
access controls.
As far as additional socket classes are concerned, it does some
reasonable to add more than just AF_ALG in an effort to try and
consolidate things. Guido, is this something you would be willing to
work on?
--
paul moore
www.paul-moore.com
next prev parent reply other threads:[~2016-08-23 13:35 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-20 16:18 [PATCH] Differentiate between Unix Stream Socket and Sequential Packet Socket Guido Trentalancia
2016-08-20 17:17 ` Paul Moore
2016-08-20 17:39 ` Guido Trentalancia
2016-08-20 18:44 ` Paul Moore
2016-08-20 19:09 ` Guido Trentalancia
2016-08-21 3:24 ` Paul Moore
2016-08-21 17:17 ` [PATCH v2] " Guido Trentalancia
2016-08-22 13:02 ` [PATCH v3] Classify AF_ALG sockets (was: Differentiate between Unix Stream Socket and Sequential Packet Socket) Guido Trentalancia
2016-08-22 20:17 ` Paul Moore
2016-08-22 21:07 ` Guido Trentalancia
2016-08-22 21:04 ` [PATCH v4] Classify AF_ALG sockets Guido Trentalancia
2016-08-22 22:36 ` Paul Moore
2016-08-23 13:05 ` Stephen Smalley
2016-08-23 13:35 ` Paul Moore [this message]
2016-08-23 14:14 ` [PATCH v5] " Guido Trentalancia
2016-08-23 14:42 ` Stephen Smalley
2016-08-23 15:21 ` [PATCH] Update libsepol to support the policy capability for " Guido Trentalancia
2016-08-23 22:02 ` [PATCH v5] Classify " Paul Moore
2016-08-23 23:03 ` Guido Trentalancia
2016-08-21 17:31 ` [PATCH] Differentiate between Unix Stream Socket and Sequential Packet Socket Guido Trentalancia
2016-08-21 17:32 ` Guido Trentalancia
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='CAHC9VhQ08yOuosiApLSLCxoP73YSY=igrwJ7kO3qvR1uMwBJoQ@mail.gmail.com' \
--to=paul@paul-moore.com \
--cc=guido@trentalancia.net \
--cc=sds@tycho.nsa.gov \
--cc=selinux@tycho.nsa.gov \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.