Re: [SECILC] does not seem to filter redundant attributes and rules

[Gary Tierney]

On Wed, Nov 09, 2016 at 09:52:35AM -0500, James Carter wrote:
> On 11/09/2016 07:40 AM, Dominick Grift wrote:
> >I am in the process of a DSSP rewrite, taking a different approach this
> >time.
> >
> >However I encountered something that seems suboptimal:
> >
> >SECILC seems to not filter redundant attributes and rules
> >
> >Example i have a type attribute and it has rules associated with it.
> >However, the type attribute is not associated with any types.
> >
> >I was hoping that SECILC would be smart enough to determine that it
> >might as well filter both the type attribute as well as the rules
> >associated with it.
> >
> >To reproduce:
> >
> >git clone https://github.com/DefenSec/dssp1-base.git
> >cd dssp1-base
> >secilc `ls *.cil`
> >sesearch -ASCT -s lib.ld_so.read_files_subj_type_attribute policy.30
> >seinfo -xalib.ld_so.read_files_subj_type_attribute policy.30
> >
> >
> >Am i expecting the impossible by expecting SECILC to be smart enough to
> >determine that something is redundant, and that it can be filtered out
> >until it becomes applicable?
> >
> >
> 
> I don't think that it would be too hard to remove attributes that have no
> types associated with them along with rules containing those attributes. I
> have this nagging feeling, though, that there is a reason that we didn't do
> that. I'll have to think about it a bit.
> 
> Jim
>

I had a hack 'n' slash attempt at this earlier for just avrules by adding
naive checks in avrule_write (libsepol/src/write.c) to check if both the
source and target type_set bitmaps have a cardinality of 0, though couldn't
help but think I was missing something else.  That didn't work in any case,
and didn't seem like the codepath is ever hit when a CIL policy is
written to disk (maybe it's only module policy avrule_write is called for?).

Any hints on where I can start prodding?  Would be nice to get an idea of how
the binary policy is serialized too.
> 
> >
> >___
> >Selinux mailing list
> >Selinux@tycho.nsa.gov
> >To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
> >To get help, send an email containing "help" to 
> >selinux-requ...@tycho.nsa.gov.
> >
> 
> 
> -- 
> James Carter 
> National Security Agency
> ___
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
> To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

-- 
Gary Tierney

GPG fingerprint: 412C 0EF9 C305 68E6 B660  BDAF 706E D765 85AA 79D8
https://sks-keyservers.net/pks/lookup?op=get=0x706ED76585AA79D8


signature.asc
Description: PGP signature
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [PATCH 1/1 V2] mqueue: Implment generic xattr support

[William Roberts]

On Nov 9, 2016 08:33, "David Graziano" 
wrote:
>
> On Mon, Nov 7, 2016 at 4:23 PM, Paul Moore  wrote:
> > On Mon, Nov 7, 2016 at 3:46 PM, David Graziano
> >  wrote:
> >> This patch adds support for generic extended attributes within the
> >> POSIX message queues filesystem and setting them by consulting the LSM.
> >> This is needed so that the security.selinux extended attribute can be
> >> set via a SELinux named type transition on file inodes created within
> >> the filesystem. The implementation and LSM call back function are based
> >> off tmpfs/shmem.
> >>
> >> Signed-off-by: David Graziano 
> >> ---
> >>  ipc/mqueue.c | 46 ++
> >>  1 file changed, 46 insertions(+)
> >
> > Hi David,
> >
> > At first glance this looks reasonable to me, I just have a two
> > questions/comments:
> >
> > * Can you explain your current need for this functionality?  For
> > example, what are you trying to do that is made easier by allowing
> > greater message queue labeling flexibility?  This helps put things in
> > context and helps people review and comment on your patch.
> >
> > * How have you tested this?  While this patch is not SELinux specific,
> > I think adding a test to the selinux-testsuite[1] would be worthwhile.
> > The other LSM maintainers may suggest something similar if they have
> > an established public testsuite.
> >
> > [1] https://github.com/SELinuxProject/selinux-testsuite
>
> Hi Paul,
>
> I needed to write a selinux policy for a set of custom applications that
use
> POSIX message queues for their IPC. The queues are created by one
> application and we needed a way for selinux to enforce which of the other
> apps are able to read/write to each individual queue. Uniquely labeling
them
> based on the app that created them and the file name seemed to be our best
> solution since it’s an embedded system and we don’t have restorecond to
> handle any relabeling.

I've actually needed this before, so ack from me.

>
>
> To test this patch I used both a selinux enabled, buildroot based qemu
target
> with a customized selinux policy and test C app to create the mqueues. I
also
> tested with our real apps and selinux policy on our target hardware. I can
> certainly look at adding a test to the selinux-testsuite if that would
> be helpful.
>
> Thanks,
> David
>
> >
> >> diff --git a/ipc/mqueue.c b/ipc/mqueue.c
> >> index 0b13ace..512a546 100644
> >> --- a/ipc/mqueue.c
> >> +++ b/ipc/mqueue.c
> >> @@ -35,6 +35,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>
> >>  #include 
> >>  #include "util.h"
> >> @@ -70,6 +71,7 @@ struct mqueue_inode_info {
> >> struct rb_root msg_tree;
> >> struct posix_msg_tree_node *node_cache;
> >> struct mq_attr attr;
> >> +   struct simple_xattrs xattrs;/* list of xattrs */
> >>
> >> struct sigevent notify;
> >> struct pid *notify_owner;
> >> @@ -254,6 +256,7 @@ static struct inode *mqueue_get_inode(struct
super_block *sb,
> >> info->attr.mq_maxmsg = attr->mq_maxmsg;
> >> info->attr.mq_msgsize = attr->mq_msgsize;
> >> }
> >> +   simple_xattrs_init(>xattrs);
> >> /*
> >>  * We used to allocate a static array of pointers and
account
> >>  * the size of that array as well as one msg_msg
struct per
> >> @@ -413,6 +416,41 @@ static void mqueue_evict_inode(struct inode
*inode)
> >> put_ipc_ns(ipc_ns);
> >>  }
> >>
> >> +/*
> >> + * Callback for security_inode_init_security() for acquiring xattrs.
> >> + */
> >> +static int mqueue_initxattrs(struct inode *inode,
> >> +   const struct xattr *xattr_array,
> >> +   void *fs_info)
> >> +{
> >> +   struct mqueue_inode_info *info = MQUEUE_I(inode);
> >> +   const struct xattr *xattr;
> >> +   struct simple_xattr *new_xattr;
> >> +   size_t len;
> >> +
> >> +   for (xattr = xattr_array; xattr->name != NULL; xattr++) {
> >> +   new_xattr = simple_xattr_alloc(xattr->value,
xattr->value_len);
> >> +   if (!new_xattr)
> >> +   return -ENOMEM;
> >> +   len = strlen(xattr->name) + 1;
> >> +   new_xattr->name = kmalloc(XATTR_SECURITY_PREFIX_LEN +
len,
> >> + GFP_KERNEL);
> >> +   if (!new_xattr->name) {
> >> +   kfree(new_xattr);
> >> +   return -ENOMEM;
> >> +   }
> >> +
> >> +   memcpy(new_xattr->name, XATTR_SECURITY_PREFIX,
> >> +  XATTR_SECURITY_PREFIX_LEN);
> >> +   memcpy(new_xattr->name + XATTR_SECURITY_PREFIX_LEN,
> >> +  xattr->name, len);
> >> +
> >> +   

Re: [PATCH 1/1 V2] mqueue: Implment generic xattr support

[David Graziano]

On Mon, Nov 7, 2016 at 4:23 PM, Paul Moore  wrote:
> On Mon, Nov 7, 2016 at 3:46 PM, David Graziano
>  wrote:
>> This patch adds support for generic extended attributes within the
>> POSIX message queues filesystem and setting them by consulting the LSM.
>> This is needed so that the security.selinux extended attribute can be
>> set via a SELinux named type transition on file inodes created within
>> the filesystem. The implementation and LSM call back function are based
>> off tmpfs/shmem.
>>
>> Signed-off-by: David Graziano 
>> ---
>>  ipc/mqueue.c | 46 ++
>>  1 file changed, 46 insertions(+)
>
> Hi David,
>
> At first glance this looks reasonable to me, I just have a two
> questions/comments:
>
> * Can you explain your current need for this functionality?  For
> example, what are you trying to do that is made easier by allowing
> greater message queue labeling flexibility?  This helps put things in
> context and helps people review and comment on your patch.
>
> * How have you tested this?  While this patch is not SELinux specific,
> I think adding a test to the selinux-testsuite[1] would be worthwhile.
> The other LSM maintainers may suggest something similar if they have
> an established public testsuite.
>
> [1] https://github.com/SELinuxProject/selinux-testsuite

Hi Paul,

I needed to write a selinux policy for a set of custom applications that use
POSIX message queues for their IPC. The queues are created by one
application and we needed a way for selinux to enforce which of the other
apps are able to read/write to each individual queue. Uniquely labeling them
based on the app that created them and the file name seemed to be our best
solution since it’s an embedded system and we don’t have restorecond to
handle any relabeling.


To test this patch I used both a selinux enabled, buildroot based qemu target
with a customized selinux policy and test C app to create the mqueues. I also
tested with our real apps and selinux policy on our target hardware. I can
certainly look at adding a test to the selinux-testsuite if that would
be helpful.

Thanks,
David

>
>> diff --git a/ipc/mqueue.c b/ipc/mqueue.c
>> index 0b13ace..512a546 100644
>> --- a/ipc/mqueue.c
>> +++ b/ipc/mqueue.c
>> @@ -35,6 +35,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  #include 
>>  #include "util.h"
>> @@ -70,6 +71,7 @@ struct mqueue_inode_info {
>> struct rb_root msg_tree;
>> struct posix_msg_tree_node *node_cache;
>> struct mq_attr attr;
>> +   struct simple_xattrs xattrs;/* list of xattrs */
>>
>> struct sigevent notify;
>> struct pid *notify_owner;
>> @@ -254,6 +256,7 @@ static struct inode *mqueue_get_inode(struct super_block 
>> *sb,
>> info->attr.mq_maxmsg = attr->mq_maxmsg;
>> info->attr.mq_msgsize = attr->mq_msgsize;
>> }
>> +   simple_xattrs_init(>xattrs);
>> /*
>>  * We used to allocate a static array of pointers and account
>>  * the size of that array as well as one msg_msg struct per
>> @@ -413,6 +416,41 @@ static void mqueue_evict_inode(struct inode *inode)
>> put_ipc_ns(ipc_ns);
>>  }
>>
>> +/*
>> + * Callback for security_inode_init_security() for acquiring xattrs.
>> + */
>> +static int mqueue_initxattrs(struct inode *inode,
>> +   const struct xattr *xattr_array,
>> +   void *fs_info)
>> +{
>> +   struct mqueue_inode_info *info = MQUEUE_I(inode);
>> +   const struct xattr *xattr;
>> +   struct simple_xattr *new_xattr;
>> +   size_t len;
>> +
>> +   for (xattr = xattr_array; xattr->name != NULL; xattr++) {
>> +   new_xattr = simple_xattr_alloc(xattr->value, 
>> xattr->value_len);
>> +   if (!new_xattr)
>> +   return -ENOMEM;
>> +   len = strlen(xattr->name) + 1;
>> +   new_xattr->name = kmalloc(XATTR_SECURITY_PREFIX_LEN + len,
>> + GFP_KERNEL);
>> +   if (!new_xattr->name) {
>> +   kfree(new_xattr);
>> +   return -ENOMEM;
>> +   }
>> +
>> +   memcpy(new_xattr->name, XATTR_SECURITY_PREFIX,
>> +  XATTR_SECURITY_PREFIX_LEN);
>> +   memcpy(new_xattr->name + XATTR_SECURITY_PREFIX_LEN,
>> +  xattr->name, len);
>> +
>> +   simple_xattr_list_add(>xattrs, new_xattr);
>> +   }
>> +
>> +   return 0;
>> +}
>> +
>>  static int mqueue_create(struct inode *dir, struct dentry *dentry,
>> umode_t mode, bool excl)
>>  {
>> @@ -443,6 +481,14 @@ static int mqueue_create(struct inode *dir, struct 
>> dentry *dentry,
>> 

Re: [PATCH v4 9/9] selinux: Add a cache for quicker retreival of PKey SIDs

[Daniel Jurgens]

On 11/9/2016 1:05 AM, Leon Romanovsky wrote:
> On Tue, Nov 08, 2016 at 11:06:25PM +0200, Dan Jurgens wrote:
>> From: Daniel Jurgens 
>>
>> It is likely that the SID for the same PKey will be requested many
>> times. To reduce the time to modify QPs and process MADs use a cache to
>> store PKey SIDs.
>>
>> This code is heavily based on the "netif" and "netport" concept
>> originally developed by James Morris  and Paul Moore
>>  (see security/selinux/netif.c and
>> security/selinux/netport.c for more information)
>>
>> issue: 736423
>> Change-Id: I176c3079d5d84d06839b4f750100ac47a6081e94
> It doesn't belong to commit message.
>
>> Signed-off-by: Daniel Jurgens 

Yes, sorry silly oversight on my part.  I will address for all patches in v5.


___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [PATCH v4 9/9] selinux: Add a cache for quicker retreival of PKey SIDs

[Leon Romanovsky]

On Tue, Nov 08, 2016 at 11:06:25PM +0200, Dan Jurgens wrote:
> From: Daniel Jurgens 
>
> It is likely that the SID for the same PKey will be requested many
> times. To reduce the time to modify QPs and process MADs use a cache to
> store PKey SIDs.
>
> This code is heavily based on the "netif" and "netport" concept
> originally developed by James Morris  and Paul Moore
>  (see security/selinux/netif.c and
> security/selinux/netport.c for more information)
>
> issue: 736423
> Change-Id: I176c3079d5d84d06839b4f750100ac47a6081e94

It doesn't belong to commit message.

> Signed-off-by: Daniel Jurgens 


signature.asc
Description: PGP signature
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [PATCH v4 3/9] selinux lsm IB/core: Implement LSM notification system

[Daniel Jurgens]

On 11/8/2016 4:36 PM, kbuild test robot wrote:
> Hi Daniel,
>
> [auto build test ERROR on rdma/master]
> [also build test ERROR on v4.9-rc4]
> [cannot apply to next-20161108]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Dan-Jurgens/SELinux-support-for-Infiniband-RDMA/20161109-053432
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git 
> master
> config: i386-randconfig-s1-201645 (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386 
>
> All errors (new ones prefixed by >>):
>
>>> ERROR: "unregister_lsm_notifier" [drivers/infiniband/core/ib_core.ko] 
>>> undefined!
>>> ERROR: "register_lsm_notifier" [drivers/infiniband/core/ib_core.ko] 
>>> undefined!
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation

This link error happens when CONFIG_SECURITY is not set.  I will address it in 
v5 after giving some time for additional comments.


___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

Re: [PATCH v4 3/9] selinux lsm IB/core: Implement LSM notification system

[kbuild test robot]

Hi Daniel,

[auto build test ERROR on rdma/master]
[also build test ERROR on v4.9-rc4]
[cannot apply to next-20161108]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Dan-Jurgens/SELinux-support-for-Infiniband-RDMA/20161109-053432
base:   https://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git master
config: i386-randconfig-s1-201645 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> ERROR: "unregister_lsm_notifier" [drivers/infiniband/core/ib_core.ko] 
>> undefined!
>> ERROR: "register_lsm_notifier" [drivers/infiniband/core/ib_core.ko] 
>> undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.

[SECILC] does not seem to filter redundant attributes and rules

[Dominick Grift]

I am in the process of a DSSP rewrite, taking a different approach this
time.

However I encountered something that seems suboptimal:

SECILC seems to not filter redundant attributes and rules

Example i have a type attribute and it has rules associated with it.
However, the type attribute is not associated with any types.

I was hoping that SECILC would be smart enough to determine that it
might as well filter both the type attribute as well as the rules
associated with it.

To reproduce:

git clone https://github.com/DefenSec/dssp1-base.git
cd dssp1-base
secilc `ls *.cil`
sesearch -ASCT -s lib.ld_so.read_files_subj_type_attribute policy.30
seinfo -xalib.ld_so.read_files_subj_type_attribute policy.30


Am i expecting the impossible by expecting SECILC to be smart enough to
determine that something is redundant, and that it can be filtered out
until it becomes applicable?

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift



signature.asc
Description: OpenPGP digital signature
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.