Re: ANN: SELinux userspace 2.8-rc1 release candidate

2018-04-23 Thread Nicolas Iooss 
On Thu, Apr 19, 2018 at 5:07 PM, Stephen Smalley  wrote:
> A 2.8-rc1 release candidate for the SELinux userspace is now available at:
> https://github.com/SELinuxProject/selinux/wiki/Releases
>
> Please give it a test and let us know if there are any issues.
>
> If there are specific changes that you think should be called out in
> release notes for packagers and users in the final release announcement, let 
> us know.
>
> Thanks to all the contributors to this release candidate!

Thanks for this release! I have built and installed Arch Linux
packages for it and have not experimented any noticeable issue.

Here are some notes which could be useful for packagers:

* Important notice: when overriding PREFIX, BINDIR, SBINDIR, SHLIBDIR,
LIBEXECDIR, etc., DESTDIR has to be removed from the definition. For
example on Arch Linux, I had to change SBINDIR="${pkgdir}/usr/bin" to
SBINDIR="/usr/bin".
* Defining variable LIBSEPOLA (to /usr/lib/libsepol.a, for example) is
no longer mandatory (thanks to the switch to "-l:libsepol.a" in
Makefiles).
* Still in Makfiles, PYSITEDIR has been renamed PYTHONLIBDIR (and its
definition changed).
* selinux-gui (ie. system-config-selinux GUI application) is now
compatible with Python 3. Doing this required migrating away from
PyGTK to the supported PyGI library. This means that selinux-gui now
depends on python-gobject, Gtk+ 3 and selinux-python. It no longer
requires PyGtk or Python 2.

By the way, for Arch Linux users who want to test the RC, I have
published the PKGBUILDs I have written on branch "selinux-2.8-rc" of
https://github.com/archlinuxhardened/selinux/commits/selinux-2.8-rc .

Cheers,
Nicolas

Re: [PATCH 0/3] Introduce LSM-hook for socketpair(2)

2018-04-23 Thread Serge E. Hallyn 
Quoting David Herrmann (dh.herrm...@gmail.com):
> Hi
> 
> This series adds a new LSM hook for the socketpair(2) syscall. The idea
> is to allow SO_PEERSEC to be called on AF_UNIX sockets created via
> socketpair(2), and return the same information as if you emulated
> socketpair(2) via a temporary listener socket. Right now SO_PEERSEC
> will return the unlabeled credentials for a socketpair, rather than the
> actual credentials of the creating process.
> 
> A simple call to:
> 
> socketpair(AF_UNIX, SOCK_STREAM, 0, out);
> 
> can be emulated via a temporary listener socket bound to a unique,
> random name in the abstract namespace. By connecting to this listener
> socket, accept(2) will return the second part of the pair. If
> SO_PEERSEC is queried on these, the correct credentials of the creating
> process are returned. A simple comparison between the behavior of
> SO_PEERSEC on socketpair(2) and an emulated socketpair is included in
> the dbus-broker test-suite [1].
> 
> This patch series tries to close this gap and makes both behave the
> same. A new LSM-hook is added which allows LSMs to cache the correct
> peer information on newly created socket-pairs.
> 
> Apart from fixing this behavioral difference, the dbus-broker project
> actually needs to query the credentials of socketpairs, and currently
> must resort to racy procfs(2) queries to get the LSM credentials of its
> controller socket. Several parts of the dbus-broker project allow you
> to pass in a socket during execve(2), which will be used by the child
> process to accept control-commands from its parent. One natural way to
> create this communication channel is to use socketpair(2). However,
> right now SO_PEERSEC does not return any useful information, hence, the
> child-process would need other means to retrieve this information. By
> avoiding socketpair(2) and using the hacky-emulated version, this is not
> an issue.
> 
> There was a previous discussion on this matter [2] roughly a year ago.
> Back then there was the suspicion that proper SO_PEERSEC would confuse
> applications. However, we could not find any evidence backing this
> suspicion. Furthermore, we now actually see the contrary. Lack of
> SO_PEERSEC makes it a hassle to use socketpairs with LSM credentials.
> Hence, we propose to implement full SO_PEERSEC for socketpairs.
> 
> This series only adds SELinux backends, since that is what we need for
> RHEL. I will gladly extend the other LSMs if needed.
> 
> Thanks
> David
> 
> [1] https://github.com/bus1/dbus-broker/blob/master/src/util/test-peersec.c
> [2] https://www.spinics.net/lists/selinux/msg22674.html
> 
> David Herrmann (3):
>   security: add hook for socketpair(AF_UNIX, ...)
>   net/unix: hook unix_socketpair() into LSM
>   selinux: provide unix_stream_socketpair callback
> 
>  include/linux/lsm_hooks.h |  8 
>  include/linux/security.h  |  7 +++
>  net/unix/af_unix.c|  5 +
>  security/security.c   |  6 ++
>  security/selinux/hooks.c  | 14 ++
>  5 files changed, 40 insertions(+)

Makes sense to me, thanks.

Acked-by: Serge Hallyn

Re: [PATCH 0/3] Introduce LSM-hook for socketpair(2)

2018-04-23 Thread Casey Schaufler 
On 4/23/2018 6:30 AM, David Herrmann wrote:
> Hi
>
> This series adds a new LSM hook for the socketpair(2) syscall. The idea
> is to allow SO_PEERSEC to be called on AF_UNIX sockets created via
> socketpair(2), and return the same information as if you emulated
> socketpair(2) via a temporary listener socket. Right now SO_PEERSEC
> will return the unlabeled credentials for a socketpair, rather than the
> actual credentials of the creating process.
>
> ...
>
> This series only adds SELinux backends, since that is what we need for
> RHEL. I will gladly extend the other LSMs if needed.

I would be very happy to see a proposed patch for Smack. It shouldn't
be much different from the SELinux version, with the exception that it
will use pointers to smk_known structures instead of secids. It would be
a big help, as someone just threw a whole new species of scorpion into
this pit.

>
> Thanks
> David
>
> [1] https://github.com/bus1/dbus-broker/blob/master/src/util/test-peersec.c
> [2] https://www.spinics.net/lists/selinux/msg22674.html
>
> David Herrmann (3):
>   security: add hook for socketpair(AF_UNIX, ...)
>   net/unix: hook unix_socketpair() into LSM
>   selinux: provide unix_stream_socketpair callback
>
>  include/linux/lsm_hooks.h |  8 
>  include/linux/security.h  |  7 +++
>  net/unix/af_unix.c|  5 +
>  security/security.c   |  6 ++
>  security/selinux/hooks.c  | 14 ++
>  5 files changed, 40 insertions(+)
>

Re: [PATCH 2/2] sestatus: free process and file contexts which are checked

2018-04-23 Thread William Roberts 
On Sun, Apr 22, 2018 at 12:21 PM, Nicolas Iooss  wrote:
> clang's static analyzer reports a potential memory leak because the
> buffers allocated in pc and fc are not freed in main(), in sestatus.c.
> Free these buffers properly.
>
> Signed-off-by: Nicolas Iooss 
> ---
>  policycoreutils/sestatus/sestatus.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/policycoreutils/sestatus/sestatus.c 
> b/policycoreutils/sestatus/sestatus.c
> index d7f198c2fa0d..9a92e72ff4fd 100644
> --- a/policycoreutils/sestatus/sestatus.c
> +++ b/policycoreutils/sestatus/sestatus.c
> @@ -436,6 +436,7 @@ int main(int argc, char **argv)
> printf("%s\n", context);
> freecon(context);
> }
> +   free(pc[i]);
> }
>
> printf("\nFile contexts:\n");
> @@ -478,6 +479,7 @@ int main(int argc, char **argv)
> freecon(context);
> }
> }
> +   free(fc[i]);
> }
>
> return 0;
> --
> 2.17.0
>
>
ack on both patches in this series.

Re: Alias path subbing results in unexpected policy labelling

2018-04-23 Thread Petr Lautrbach 
On Mon, Apr 23, 2018 at 04:21:22PM +, Joe Kirwin wrote:
> Petr, Daniel,
> 
> Have you had time to verify this issue yet?
> Any comments to add?
> 

I consider this as the expected behavior.

It's defined as "Substitute target path with sourcepath when generating default
 label." It means that /apple is substituted for /banana and the lookup is made
 for /banana/orange/foo.

On the other hand, `semanage-fcontext` man page and `semanage fcontext -h`
output could be misleading a bit as they use words "EQUAL" and "equivalent"
while it's not a symmetric relation, it's just a substitution.

I don't have an opinion about proposed change to have a real equivalence. It
could complicate some things a lot and the benefit is not clear to me right now.

Petr

>
> On Tue, Mar 20, 2018 at 8:14 AM Stephen Smalley  wrote:
> 
> > On 03/19/2018 10:29 PM, Joe Kirwin wrote:
> > > *_Empirical Observations _*
> > > *
> > > *
> > > If I was to create an SELinux policy containing the following
> > file_contexts (fruits.fc)
> > > ```
> > > /apple/orange/.*  --
> > gen_context(system_u:object_r:atype_t,s0)
> > > /banana/.*   --
> > gen_context(system_u:object_r:btype_t,s0)
> > > ```
> > >
> > > If I then take the file
> > > /etc/selinux/default/contexts/files/file_contexts.subs_dist and append
> > to it the alias
> > > ```
> > > /apple /banana
> > > ```
> > >
> > > The resulting behavior is that when running:
> > > ```
> > > $ ./libselinux/utils/selabel_lookup_best_match -p /apple/orange/foo
> > > Best match context: system_u:object_r:btype_t:s0
> > >
> > > But the expected behavior is to match `atype_t` as that is a
> > "more-specific" match pattern
> >
> > I don't think this is a bug based on the documented behavior for
> > file_contexts.subs.  That said,
> > that support was added by Red Hat so I'll let them speak to it.
> >
> > >
> > > *_Looking into why_*
> > >
> > > From the method in `libselinux/src/label_file.c` :
> > >   lookup_common(struct selabel_handle *rec, const
> > char *key, int type, bool partial)
> > >
> > > we encounter a call to :
> > >  selabel_sub_key(struct saved_data *data, const char
> > *key)
> > >
> > > In the example above the candidate path we're trying to match (referred
> > to as the key in the code) is "canonicalized" to the /banana alias but the
> > regex being evaluated is not
> > >
> > > *_A proposed fix_*
> > > *
> > > *
> > > /Also attached (label_file.patch), if the patch formatting is off on
> > this thread, apologies./
> > > *
> > > *
> > > diff --git a/libselinux/src/label_file.c b/libselinux/src/label_file.c
> > > index 560d8c3..98a8d1b 100644
> > > --- a/libselinux/src/label_file.c
> > > +++ b/libselinux/src/label_file.c
> > > @@ -848,7 +848,7 @@ static struct spec *lookup_common(struct
> > selabel_handle *rec,
> > >  {
> > > struct saved_data *data = (struct saved_data *)rec->data;
> > > struct spec *spec_arr = data->spec_arr;
> > > -   int i, rc, file_stem;
> > > +   int i, rc, file_stem, orig_file_stem;
> > > mode_t mode = (mode_t)type;
> > > const char *buf;
> > > struct spec *ret = NULL;
> > > @@ -879,8 +879,12 @@ static struct spec *lookup_common(struct
> > selabel_handle *rec,
> > > }
> > >
> > > sub = selabel_sub_key(data, key);
> > > -   if (sub)
> > > +   orig_file_stem = -1;
> > > +   if (sub) {
> > > +  orig_file_stem = find_stem_from_file(data, );
> > > key = sub;
> > > +   }
> > >
> > > buf = key;
> > > file_stem = find_stem_from_file(data, );
> > > @@ -896,7 +900,8 @@ static struct spec *lookup_common(struct
> > selabel_handle *rec,
> > >  * stem as the file AND if the spec in question has no mode
> > >  * specified or if the mode matches the file mode then we do
> > >  * a regex check*/
> > > -   if ((spec->stem_id == -1 || spec->stem_id == file_stem) &&
> > > +   if ((spec->stem_id == -1 || spec->stem_id == file_stem ||
> > > +spec->stem_id == orig_file_stem) &&
> > > (!mode || !spec->mode || mode == spec->mode)) {
> > > if (compile_regex(data, spec, NULL) < 0)
> > > goto finish;
> > >
> > >
> > >
> > > I think there is still some simplification that could be done with
> > aliases, in that they really shouldn't have a direction (e.g. alias ->
> > original) instead they should go both ways and if there is a tie it should
> > go by the ordering of the specs.
> > > Reason for this is that a developer of an SELinux policy, may not know
> > the contents or directionality of file_contexts.subs_dist ahead of time or
> > when it might change.
> > >
> > > Thanks,
> > > Joe Kirwin and Travis Szucs
> > >
> >
> > --
> -- 
> *Joe Kirwin*  |  *Senior Security Developer_*
> *E:* j...@cmd.com    *M:* 1.604.365.2823
> 
>

Re: [PATCH 3/3] selinux: provide unix_stream_socketpair callback

2018-04-23 Thread Stephen Smalley 
On 04/23/2018 09:30 AM, David Herrmann wrote:
> Make sure to implement the new unix_stream_socketpair callback so the
> SO_PEERSEC call on socketpair(2)s will return correct information.
> 
> Signed-off-by: David Herrmann 

Acked-by: Stephen Smalley 

> ---
>  security/selinux/hooks.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 4cafe6a19167..828881d9a41d 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -4905,6 +4905,18 @@ static int selinux_socket_unix_stream_connect(struct 
> sock *sock,
>   return 0;
>  }
>  
> +static int selinux_socket_unix_stream_socketpair(struct sock *socka,
> +  struct sock *sockb)
> +{
> + struct sk_security_struct *sksec_a = socka->sk_security;
> + struct sk_security_struct *sksec_b = sockb->sk_security;
> +
> + sksec_a->peer_sid = sksec_b->sid;
> + sksec_b->peer_sid = sksec_a->sid;
> +
> + return 0;
> +}
> +
>  static int selinux_socket_unix_may_send(struct socket *sock,
>   struct socket *other)
>  {
> @@ -6995,6 +7007,8 @@ static struct security_hook_list selinux_hooks[] 
> __lsm_ro_after_init = {
>   LSM_HOOK_INIT(inode_getsecctx, selinux_inode_getsecctx),
>  
>   LSM_HOOK_INIT(unix_stream_connect, selinux_socket_unix_stream_connect),
> + LSM_HOOK_INIT(unix_stream_socketpair,
> + selinux_socket_unix_stream_socketpair),
>   LSM_HOOK_INIT(unix_may_send, selinux_socket_unix_may_send),
>  
>   LSM_HOOK_INIT(socket_create, selinux_socket_create),
>

Re: Alias path subbing results in unexpected policy labelling

2018-04-23 Thread Joe Kirwin 
Petr, Daniel,

Have you had time to verify this issue yet?
Any comments to add?

Thanks,
Joe

On Tue, Mar 20, 2018 at 8:14 AM Stephen Smalley  wrote:

> On 03/19/2018 10:29 PM, Joe Kirwin wrote:
> > *_Empirical Observations _*
> > *
> > *
> > If I was to create an SELinux policy containing the following
> file_contexts (fruits.fc)
> > ```
> > /apple/orange/.*  --
> gen_context(system_u:object_r:atype_t,s0)
> > /banana/.*   --
> gen_context(system_u:object_r:btype_t,s0)
> > ```
> >
> > If I then take the file
> > /etc/selinux/default/contexts/files/file_contexts.subs_dist and append
> to it the alias
> > ```
> > /apple /banana
> > ```
> >
> > The resulting behavior is that when running:
> > ```
> > $ ./libselinux/utils/selabel_lookup_best_match -p /apple/orange/foo
> > Best match context: system_u:object_r:btype_t:s0
> >
> > But the expected behavior is to match `atype_t` as that is a
> "more-specific" match pattern
>
> I don't think this is a bug based on the documented behavior for
> file_contexts.subs.  That said,
> that support was added by Red Hat so I'll let them speak to it.
>
> >
> > *_Looking into why_*
> >
> > From the method in `libselinux/src/label_file.c` :
> >   lookup_common(struct selabel_handle *rec, const
> char *key, int type, bool partial)
> >
> > we encounter a call to :
> >  selabel_sub_key(struct saved_data *data, const char
> *key)
> >
> > In the example above the candidate path we're trying to match (referred
> to as the key in the code) is "canonicalized" to the /banana alias but the
> regex being evaluated is not
> >
> > *_A proposed fix_*
> > *
> > *
> > /Also attached (label_file.patch), if the patch formatting is off on
> this thread, apologies./
> > *
> > *
> > diff --git a/libselinux/src/label_file.c b/libselinux/src/label_file.c
> > index 560d8c3..98a8d1b 100644
> > --- a/libselinux/src/label_file.c
> > +++ b/libselinux/src/label_file.c
> > @@ -848,7 +848,7 @@ static struct spec *lookup_common(struct
> selabel_handle *rec,
> >  {
> > struct saved_data *data = (struct saved_data *)rec->data;
> > struct spec *spec_arr = data->spec_arr;
> > -   int i, rc, file_stem;
> > +   int i, rc, file_stem, orig_file_stem;
> > mode_t mode = (mode_t)type;
> > const char *buf;
> > struct spec *ret = NULL;
> > @@ -879,8 +879,12 @@ static struct spec *lookup_common(struct
> selabel_handle *rec,
> > }
> >
> > sub = selabel_sub_key(data, key);
> > -   if (sub)
> > +   orig_file_stem = -1;
> > +   if (sub) {
> > +  orig_file_stem = find_stem_from_file(data, );
> > key = sub;
> > +   }
> >
> > buf = key;
> > file_stem = find_stem_from_file(data, );
> > @@ -896,7 +900,8 @@ static struct spec *lookup_common(struct
> selabel_handle *rec,
> >  * stem as the file AND if the spec in question has no mode
> >  * specified or if the mode matches the file mode then we do
> >  * a regex check*/
> > -   if ((spec->stem_id == -1 || spec->stem_id == file_stem) &&
> > +   if ((spec->stem_id == -1 || spec->stem_id == file_stem ||
> > +spec->stem_id == orig_file_stem) &&
> > (!mode || !spec->mode || mode == spec->mode)) {
> > if (compile_regex(data, spec, NULL) < 0)
> > goto finish;
> >
> >
> >
> > I think there is still some simplification that could be done with
> aliases, in that they really shouldn't have a direction (e.g. alias ->
> original) instead they should go both ways and if there is a tie it should
> go by the ordering of the specs.
> > Reason for this is that a developer of an SELinux policy, may not know
> the contents or directionality of file_contexts.subs_dist ahead of time or
> when it might change.
> >
> > Thanks,
> > Joe Kirwin and Travis Szucs
> >
>
> --
-- 
*Joe Kirwin*  |  *Senior Security Developer_*
*E:* j...@cmd.com    *M:* 1.604.365.2823

[PATCH 3/3] selinux: provide unix_stream_socketpair callback

2018-04-23 Thread David Herrmann 
Make sure to implement the new unix_stream_socketpair callback so the
SO_PEERSEC call on socketpair(2)s will return correct information.

Signed-off-by: David Herrmann 
---
 security/selinux/hooks.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 4cafe6a19167..828881d9a41d 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -4905,6 +4905,18 @@ static int selinux_socket_unix_stream_connect(struct 
sock *sock,
return 0;
 }
 
+static int selinux_socket_unix_stream_socketpair(struct sock *socka,
+struct sock *sockb)
+{
+   struct sk_security_struct *sksec_a = socka->sk_security;
+   struct sk_security_struct *sksec_b = sockb->sk_security;
+
+   sksec_a->peer_sid = sksec_b->sid;
+   sksec_b->peer_sid = sksec_a->sid;
+
+   return 0;
+}
+
 static int selinux_socket_unix_may_send(struct socket *sock,
struct socket *other)
 {
@@ -6995,6 +7007,8 @@ static struct security_hook_list selinux_hooks[] 
__lsm_ro_after_init = {
LSM_HOOK_INIT(inode_getsecctx, selinux_inode_getsecctx),
 
LSM_HOOK_INIT(unix_stream_connect, selinux_socket_unix_stream_connect),
+   LSM_HOOK_INIT(unix_stream_socketpair,
+   selinux_socket_unix_stream_socketpair),
LSM_HOOK_INIT(unix_may_send, selinux_socket_unix_may_send),
 
LSM_HOOK_INIT(socket_create, selinux_socket_create),
-- 
2.17.0

[PATCH 2/3] net/unix: hook unix_socketpair() into LSM

2018-04-23 Thread David Herrmann 
Use the newly created LSM-hook for unix_socketpair(). The default hook
return-value is 0, so behavior stays the same unless LSMs start using
this hook.

Signed-off-by: David Herrmann 
---
 net/unix/af_unix.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 68bb70a62afe..bc9705ace9b1 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -1371,6 +1371,11 @@ static int unix_stream_connect(struct socket *sock, 
struct sockaddr *uaddr,
 static int unix_socketpair(struct socket *socka, struct socket *sockb)
 {
struct sock *ska = socka->sk, *skb = sockb->sk;
+   int err;
+
+   err = security_unix_stream_socketpair(ska, skb);
+   if (err)
+   return err;
 
/* Join our sockets back to back */
sock_hold(ska);
-- 
2.17.0

[PATCH 1/3] security: add hook for socketpair(AF_UNIX, ...)

2018-04-23 Thread David Herrmann 
Right now the LSM labels for socketpairs are always uninitialized,
since there is no security hook for the socketpair() syscall. This
patch adds the required hooks so LSMs can properly label socketpairs.
This allows SO_PEERSEC to return useful information on those sockets.

Note that the behavior of socketpair() can be emulated by creating a
listener socket, connecting to it, and then discarding the initial
listener socket. With this workaround, SO_PEERSEC would return the
caller's security context. However, with socketpair(), the uninitialized
context is returned unconditionally. This is unexpected and makes
socketpair() less useful in situations where the security context is
crucial to the application.

With the new socketpair-hook this disparity can be solved by making
socketpair() return the expected security context.

Signed-off-by: David Herrmann 
---
 include/linux/lsm_hooks.h | 8 
 include/linux/security.h  | 7 +++
 security/security.c   | 6 ++
 3 files changed, 21 insertions(+)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 9d0b286f3dba..2a23c75c1541 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -717,6 +717,12 @@
  * @other contains the peer sock structure.
  * @newsk contains the new sock structure.
  * Return 0 if permission is granted.
+ * @unix_stream_socketpair:
+ * Check permissions before establishing a Unix domain stream connection
+ * for a fresh pair of sockets.
+ * @socka contains the first sock structure.
+ * @sockb contains the second sock structure.
+ * Return 0 if permission is granted and the connection was established.
  * @unix_may_send:
  * Check permissions before connecting or sending datagrams from @sock to
  * @other.
@@ -1651,6 +1657,7 @@ union security_list_options {
 #ifdef CONFIG_SECURITY_NETWORK
int (*unix_stream_connect)(struct sock *sock, struct sock *other,
struct sock *newsk);
+   int (*unix_stream_socketpair)(struct sock *socka, struct sock *sockb);
int (*unix_may_send)(struct socket *sock, struct socket *other);
 
int (*socket_create)(int family, int type, int protocol, int kern);
@@ -1919,6 +1926,7 @@ struct security_hook_heads {
struct hlist_head inode_getsecctx;
 #ifdef CONFIG_SECURITY_NETWORK
struct hlist_head unix_stream_connect;
+   struct hlist_head unix_stream_socketpair;
struct hlist_head unix_may_send;
struct hlist_head socket_create;
struct hlist_head socket_post_create;
diff --git a/include/linux/security.h b/include/linux/security.h
index 200920f521a1..be275deeda10 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -1187,6 +1187,7 @@ static inline int security_inode_getsecctx(struct inode 
*inode, void **ctx, u32
 #ifdef CONFIG_SECURITY_NETWORK
 
 int security_unix_stream_connect(struct sock *sock, struct sock *other, struct 
sock *newsk);
+int security_unix_stream_socketpair(struct sock *socka, struct sock *sockb);
 int security_unix_may_send(struct socket *sock,  struct socket *other);
 int security_socket_create(int family, int type, int protocol, int kern);
 int security_socket_post_create(struct socket *sock, int family,
@@ -1242,6 +1243,12 @@ static inline int security_unix_stream_connect(struct 
sock *sock,
return 0;
 }
 
+static inline int security_unix_stream_socketpair(struct sock *socka,
+ struct sock *sockb)
+{
+   return 0;
+}
+
 static inline int security_unix_may_send(struct socket *sock,
 struct socket *other)
 {
diff --git a/security/security.c b/security/security.c
index 7bc2fde023a7..3dfd374e84e5 100644
--- a/security/security.c
+++ b/security/security.c
@@ -1340,6 +1340,12 @@ int security_unix_stream_connect(struct sock *sock, 
struct sock *other, struct s
 }
 EXPORT_SYMBOL(security_unix_stream_connect);
 
+int security_unix_stream_socketpair(struct sock *socka, struct sock *sockb)
+{
+   return call_int_hook(unix_stream_socketpair, 0, socka, sockb);
+}
+EXPORT_SYMBOL(security_unix_stream_socketpair);
+
 int security_unix_may_send(struct socket *sock,  struct socket *other)
 {
return call_int_hook(unix_may_send, 0, sock, other);
-- 
2.17.0

Re: [PATCH 04/24] VFS: Add LSM hooks for filesystem context [ver #7]

2018-04-23 Thread Stephen Smalley 
On 04/20/2018 11:35 AM, David Howells wrote:
> Paul Moore  wrote:
> 
>> Adding the SELinux mailing list to the CC line; in the future please
>> include the SELinux mailing list on patches like this.  It would also
>> be very helpful to include "selinux" somewhere in the subject line
>> when the patch is predominately SELinux related (much like you did for
>> the other LSMs in this patchset).
> 
> I should probably evict the SELinux bits into their own patch since the point
> of this patch is the LSM hooks, not specifically SELinux's implementation
> thereof.
> 
>> I can't say I've digested all of this yet, but what SELinux testing
>> have you done with this patchset?
> 
> Using the fsopen()/fsmount() syscalls, these hooks will be made use of, say
> for NFS (which I haven't included in this list).  Even sys_mount() will make
> use of them a bit, so just booting the system does that.
> 
> Note that for SELinux these hooks don't change very much except how the
> parameters are handled.  It doesn't actually change the checks that are made -
> at least, not yet.  There are some additional syscalls under consideration
> (such as the ability to pick a live mounted filesystem into a context) that
> might require additional permits.

Neither fsopen() nor fscontext_fs_write() appear to perform any kind of up-front
permission checking (DAC or MAC), although some security hooks may be 
ultimately called
to allocate structures, parse security options, etc.  Is there a reason not 
apply a may_mount()
or similar check up front?