Re: New Blog on how SELinux blocked Docker container escape.

[面和毅]

Dear Sir,

Thanks. I was checking can we cat /etc/shadow in my testing environment.
It seems that is protected because that file's permission is set to "000".

Here is my test result;
--
--. 1 root root system_u:object_r:shadow_t:s0
1268 Oct 13 07:55 /etc/shadow

SELinux Enforcing  -> Permission Denied
SELinux Permissive -> Permission Denied
SELinux Disabled -> Permission Denied

When I changed that permission to "755";

SELinux Enforcing  -> Could cat /etc/shadow
SELinux Permissive -> Could cat /etc/shadow
SELinux Disabled -> Could cat /etc/shadow

Then in this case that escaped user could
have read access to shadow_t label.
--

That "runc" process seems to be working as unconfined_t domain;

[root@fedora25 ~]# ps axZ|grep runc
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 1578 pts/0 Sl+
0:00 runc run ctr

So, I'm not sure but I guess we would better to assign
other domain to "runc" program (no unconfined_t).

Let me check if we will run "runc" in other domain.

Kind Regards,

OMO

2017-01-18 23:14 GMT+09:00 Daniel J Walsh <dwa...@redhat.com>:
>
>
> On 01/18/2017 12:05 AM, 面和毅 wrote:
>> Dear Sir,
>>
>> I'm member of Japan-SOSS SIG(Secure OSS Special
>> Interest Group).
>> We love SELinux(12years user) and we are promoting SELinux in Japan.
>>
>> >From technical interesting(we are promoting Docker
>> with SELinux), we did PoC for CVE-2016-9962 on Fedora25.
>>
>> Then we found current SELinux(maybe policy) does not
>> mitigate that vulnerability.
>>
>> We could reproduce that vulnerability with
>> - add CAP_SYS_PTRACE to container
>> - modified runc because there’s not so much race window on runc.
>> then we think it's not so easy in usual situation.
>> Also we couldn't reproduce it on CentOS7(latest).
>>
>> We posted that PoC result on our community blog.
>> https://jsosug.github.io/post/omok-selinux-docker-20170118/
>>
>> Also we wish to argue how can we protect this kind of
>> vulnerability by using SELinux.
>>
>> Kind Regards,
>>
>> OMO
> Attempt to cat /etc/shadow in your test to see the blockage.
>
> Here is a blog I wrote on the topic.
>
> http://rhelblog.redhat.com/2017/01/13/selinux-mitigates-container-vulnerability/
>



-- 
Kazuki Omo: ka-...@sios.com
OSS  Evangelist
OSS Business Planning Dept.
CISSP #366942
Tel: +81364015149

___
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] Re-link programs after libsepol.a is updated

[Stephen Smalley]

On Tue, 2017-01-17 at 23:01 +0100, Nicolas Iooss wrote:
> On Tue, Jan 17, 2017 at 10:48 PM, Stephen Smalley 
> wrote:
> > On Sat, 2017-01-14 at 15:38 +0100, Nicolas Iooss wrote:
> > > After libsepol is modified (for example while developing new
> > features
> > > or
> > > fixing bugs), running "make install" in the top-level directory
> > does
> > > not
> > > update the programs which use libsepol.a. Add this static library
> > to
> > > the
> > > target dependencies in order to force their updates. This makes
> > > "make"
> > > use libsepol.a in the linking command without using LDLIBS.
> > >
> > > While at it, copy what commit 14d706434846 ("libselinux: Allow
> > > overriding libsepol.a location during build") introduced in
> > > libselinux
> > > Makefile by using a new LIBSEPOLA variable in all Makefiles.
> > 
> 
> > > diff --git a/libselinux/src/Makefile b/libselinux/src/Makefile
> > > index d17792c13350..5640a57d2768 100644
> > > --- a/libselinux/src/Makefile
> > > +++ b/libselinux/src/Makefile
> > > @@ -155,8 +155,8 @@ selinuxswig_python_exception.i:
> > > ../include/selinux/selinux.h
> > >  $(AUDIT2WHYLOBJ): audit2why.c
> > >       $(CC) $(filter-out -Werror, $(CFLAGS)) $(PYINC) -fPIC
> > > -DSHARED -c -o $@ $<
> > >  
> > > -$(AUDIT2WHYSO): $(AUDIT2WHYLOBJ)
> > > -     $(CC) $(CFLAGS) -shared -o $@ $^ -L. $(LDFLAGS) -lselinux
> > > $(LIBSEPOLA) $(PYLIBS) -L$(LIBDIR)
> > > +$(AUDIT2WHYSO): $(AUDIT2WHYLOBJ) $(LIBSEPOLA)
> > > +     $(CC) $(CFLAGS) -shared -o $@ $^ -L. $(LDFLAGS) -lselinux
> > > $(PYLIBS) -L$(LIBDIR)
> > 
> > Why did you change this?
> 
> When libsepol.a is updated, $(AUDIT2WHYSO) (which is a Python
> extension, named something like python3audit2why.so and installed as
> module "selinux.audit2why") was not rebuilt. Adding $(LIBSEPOLA) to
> the dependencies (in order to fix this) makes libsepol.a appear in
> the command line through $^ so I removed $(LIBSEPOLA) from the
> "$(CC)..." line.

Ok, thanks.  Applied.

___
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] checkpolicy: Fix bug in handling type declaration in optional block.

[Dominick Grift]

On 01/18/2017 10:15 PM, Dominick Grift wrote:
> On 01/18/2017 10:09 PM, James Carter wrote:
>> On 01/18/2017 03:58 PM, Dominick Grift wrote:
>>> On 01/18/2017 09:53 PM, James Carter wrote:
 Nicolas Iooss discovered that requiring a type in an optional block
 after the type has already been declared in another optional block
 results in a duplicate declaration error.

>>>
>>> from what i have been told and from experience, types cannot, reliably,
>>> be declared in optional blocks.
>>>
>>> if the above is true, then the compiler should not allow one to declare
>>> a type in an optional block in the first place
>>>
>>
>> Well, this ordering issue reported by Nicolas would definitely cause
>> their declaration to be unreliable. ;)
>>
>> I hope to make declaring types in optional blocks reliable.
> 
> That would be nice, but just so you know. This was not the issue i was
> encountering with declaring types in optionals. So even though this
> might have made things unreliable. It was not what made it unreliable
> for me.
> 

Actually, sorry. I do actually recognize the second scenario (duplicate
declaration). So this might in fact be related. I can't believe that
this ancient bug would finally be fixed. Ive been lead to believe that
this was just a fundamental limitation of module policy all this time.
My whole policy was structured on the assumption that types cannot
reliably be declared in optionals

>>
>> Jim
>>
 The following policy will trigger the error.

 optional {
   type T1;
 }

 optional {
   require { type T1; }
 }

 In this case, although symtab_insert() in libsepol properly identifies
 that the first T1 is a declaration while the second is a require, it
 will return -2 which is the return value for a duplicate declaration
 and expect the calling code to properly handle the situation. The
 caller is require_symbol() in checkpolicy and it checks if the previous
 declaration is in the current scope. If it is, then the require can be
 ignored. It also checks to see if the declaration is a type and the
 require an attribute or vice versa which is an error. The problem is
 that -2 is returned if the declaration is not in scope which is
 interpreted as a duplicate declaration error.

 The function should return 1 instead which means that they symbol was
 not
 added and needs to be freed later.

 Signed-off-by: James Carter 
 ---
  checkpolicy/module_compiler.c | 16 +++-
  1 file changed, 3 insertions(+), 13 deletions(-)

 diff --git a/checkpolicy/module_compiler.c
 b/checkpolicy/module_compiler.c
 index 6e5483c..bb60f34 100644
 --- a/checkpolicy/module_compiler.c
 +++ b/checkpolicy/module_compiler.c
 @@ -647,7 +647,6 @@ int require_symbol(uint32_t symbol_type,
  } else if (retval == -2) {
  /* ignore require statements if that symbol was
   * previously declared and is in current scope */
 -int prev_declaration_ok = 0;
  if (is_id_in_scope(symbol_type, key)) {
  if (symbol_type == SYM_TYPES) {
  /* check that previous symbol has same
 @@ -661,23 +660,14 @@ int require_symbol(uint32_t symbol_type,
  table, key);
  assert(old_datum != NULL);
  unsigned char old_isattr = old_datum->flavor;
 -prev_declaration_ok =
 -(old_isattr == new_isattr ? 1 : 0);
 -} else {
 -prev_declaration_ok = 1;
 +if (old_isattr != new_isattr)
 +return -2;
  }
 -}
 -if (prev_declaration_ok) {
  /* ignore this require statement because it
   * was already declared within my scope */
  stack_top->require_given = 1;
 -return 1;
 -} else {
 -/* previous declaration was not in scope or
 - * had a mismatched type/attribute, so
 - * generate an error */
 -return -2;
  }
 +return 1;
  } else if (retval < 0) {
  return -3;
  } else {/* fall through possible if retval is 0 or 1 */

>>>
>>>
>>>
>>>
>>> ___
>>> 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.
>>>
>>
>>
> 
> 


-- 
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

Re: [PATCH] selinux-testsuite: extend sockcreate to support other address families

[Paul Moore]

On Fri, Jan 13, 2017 at 2:10 PM, Stephen Smalley  wrote:
> Extend the sockcreate test program to support other address families.
> This is what I used to manually confirm the other extended socket classes.
> However, to avoid bloating the required kernel configuration for the
> selinux-testsuite and because some of the required kernel config options
> are not enabled in current Fedora kernels, I am not adding tests of these
> individual address families to the test script or policy.  We already test
> a representative sampling of the extended socket classes.
>
> IUCV is only supported on s390 and QIPCRTR is only supported on qcom.
> I did not test creating sockets with these two families but confirmed
> that they are supported socket families from the sources.
>
> Config options not already enabled in the Fedora kernel configs required
> to test creating sockets with these address families:
> CONFIG_CAIF=m
> CONFIG_DECNET=m
> CONFIG_LLC2=m
> CONFIG_PHONET=m
> CONFIG_X25=m
> CONFIG_AF_RXRPC=m
>
> Config options already enabled in the Fedora kernel configs required to
> test creating sockets with these address families:
> CONFIG_AX25=m
> CONFIG_NETROM=m
> CONFIG_ROSE=m
> CONFIG_ATM=m
> CONFIG_RDS=m
> CONFIG_IRDA=m
> CONFIG_MISDN=m
> CONFIG_LLC=m
> CONFIG_IPX=m
> CONFIG_CAN=m
> CONFIG_CAN_RAW=m
> CONFIG_TIPC=m
> CONFIG_L2TP=m
> CONFIG_L2TP_PPPOL2TP=m
> CONFIG_IEEE802154=m
> CONFIG_IEEE802154_SOCKET=m
> CONFIG_NFC=m
> CONFIG_VSOCKETS=m
> CONFIG_VMWARE_VMCI_VSOCKETS=m
> CONFIG_AF_KCM=m
>
> Sample invocation of sockcreate for each address family that should
> succeed (no output, exit 0):
> sockcreate atmpvc dgram default
> sockcreate atmsvc dgram default
> sockcreate ax25 dgram default
> sockcreate caif stream default
> sockcreate can raw can_raw
> sockcreate decnet stream default
> sockcreate ieee802154 dgram default
> sockcreate ipx dgram default
> sockcreate irda stream default
> sockcreate isdn raw default
> sockcreate kcm dgram default
> sockcreate llc stream default
> sockcreate netrom seqpacket default
> sockcreate nfc seqpacket default
> sockcreate phonet dgram default
> sockcreate pppox stream default
> sockcreate rds seqpacket default
> sockcreate rose seqpacket default
> sockcreate rxrpc dgram default
> sockcreate tipc stream default
> sockcreate vsock stream default
> sockcreate x25 seqpacket default
>
> Note that CAN required adding an explicit protocol value since it
> did not support creating sockets with the default/0 protocol value.
>
> Signed-off-by: Stephen Smalley 
> ---
>  tests/extended_socket_class/sockcreate.c | 34 
> 
>  1 file changed, 34 insertions(+)

Thanks, merged.  This will be more interesting once the system
policies support the new object classes, in the meantime it should be
harmless.

> diff --git a/tests/extended_socket_class/sockcreate.c 
> b/tests/extended_socket_class/sockcreate.c
> index c5802ae..ee1d8f3 100644
> --- a/tests/extended_socket_class/sockcreate.c
> +++ b/tests/extended_socket_class/sockcreate.c
> @@ -17,6 +17,36 @@ static struct nameval domains[] = {
> { "inet6", AF_INET6 },
> { "bluetooth", AF_BLUETOOTH },
> { "alg", AF_ALG },
> +   { "ax25", AF_AX25 },
> +   { "ipx", AF_IPX },
> +   { "netrom", AF_NETROM },
> +   { "atmpvc", AF_ATMPVC },
> +   { "x25", AF_X25 },
> +   { "rose", AF_ROSE },
> +   { "decnet", AF_DECnet },
> +   { "atmsvc", AF_ATMSVC },
> +   { "rds", AF_RDS },
> +   { "irda", AF_IRDA },
> +   { "pppox", AF_PPPOX },
> +   { "llc", AF_LLC },
> +   { "can", AF_CAN },
> +   { "tipc", AF_TIPC },
> +   { "iucv", AF_IUCV },
> +   { "rxrpc", AF_RXRPC },
> +   { "isdn", AF_ISDN },
> +   { "phonet", AF_PHONET },
> +   { "ieee802154", AF_IEEE802154 },
> +   { "caif", AF_CAIF },
> +   { "nfc", AF_NFC },
> +   { "vsock", AF_VSOCK },
> +#ifndef AF_KCM
> +#define AF_KCM 41
> +#endif
> +   { "kcm", AF_KCM },
> +#ifndef AF_QIPCRTR
> +#define AF_QIPCRTR 42
> +#endif
> +   { "qipcrtr", AF_QIPCRTR },
> { NULL, 0 }
>  };
>
> @@ -32,6 +62,10 @@ static struct nameval protocols[] = {
> { "icmp", IPPROTO_ICMP },
> { "icmpv6", IPPROTO_ICMPV6 },
> { "sctp", IPPROTO_SCTP },
> +#ifndef CAN_RAW
> +#define CAN_RAW 1
> +#endif
> +   { "can_raw", CAN_RAW },
> { "default", 0 },
> { NULL, 0 }
>  };
> --
> 2.7.4
>



-- 
paul moore
www.paul-moore.com
___
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] checkpolicy: Fix bug in handling type declaration in optional block.

[James Carter]

On 01/18/2017 03:58 PM, Dominick Grift wrote:

On 01/18/2017 09:53 PM, James Carter wrote:

Nicolas Iooss discovered that requiring a type in an optional block
after the type has already been declared in another optional block
results in a duplicate declaration error.



from what i have been told and from experience, types cannot, reliably,
be declared in optional blocks.

if the above is true, then the compiler should not allow one to declare
a type in an optional block in the first place



Well, this ordering issue reported by Nicolas would definitely cause their 
declaration to be unreliable. ;)


I hope to make declaring types in optional blocks reliable.

Jim


The following policy will trigger the error.

optional {
  type T1;
}

optional {
  require { type T1; }
}

In this case, although symtab_insert() in libsepol properly identifies
that the first T1 is a declaration while the second is a require, it
will return -2 which is the return value for a duplicate declaration
and expect the calling code to properly handle the situation. The
caller is require_symbol() in checkpolicy and it checks if the previous
declaration is in the current scope. If it is, then the require can be
ignored. It also checks to see if the declaration is a type and the
require an attribute or vice versa which is an error. The problem is
that -2 is returned if the declaration is not in scope which is
interpreted as a duplicate declaration error.

The function should return 1 instead which means that they symbol was not
added and needs to be freed later.

Signed-off-by: James Carter 
---
 checkpolicy/module_compiler.c | 16 +++-
 1 file changed, 3 insertions(+), 13 deletions(-)

diff --git a/checkpolicy/module_compiler.c b/checkpolicy/module_compiler.c
index 6e5483c..bb60f34 100644
--- a/checkpolicy/module_compiler.c
+++ b/checkpolicy/module_compiler.c
@@ -647,7 +647,6 @@ int require_symbol(uint32_t symbol_type,
} else if (retval == -2) {
/* ignore require statements if that symbol was
 * previously declared and is in current scope */
-   int prev_declaration_ok = 0;
if (is_id_in_scope(symbol_type, key)) {
if (symbol_type == SYM_TYPES) {
/* check that previous symbol has same
@@ -661,23 +660,14 @@ int require_symbol(uint32_t symbol_type,
table, key);
assert(old_datum != NULL);
unsigned char old_isattr = old_datum->flavor;
-   prev_declaration_ok =
-   (old_isattr == new_isattr ? 1 : 0);
-   } else {
-   prev_declaration_ok = 1;
+   if (old_isattr != new_isattr)
+   return -2;
}
-   }
-   if (prev_declaration_ok) {
/* ignore this require statement because it
 * was already declared within my scope */
stack_top->require_given = 1;
-   return 1;
-   } else {
-   /* previous declaration was not in scope or
-* had a mismatched type/attribute, so
-* generate an error */
-   return -2;
}
+   return 1;
} else if (retval < 0) {
return -3;
} else {/* fall through possible if retval is 0 or 1 */






___
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.

Re: Wrong alignment when listing user/login with semanage in French

[Laurent Bigonville]

Le 17/01/17 à 22:45, Stephen Smalley a écrit :

On Sat, 2017-01-14 at 13:48 +0100, Laurent Bigonville wrote:

Hi,

Not sure I already posted this on the ML.

When listing the user/login with semanage (login/user -l) in French
(and
probably in other languages as well), the columns headers are not
properly aligned.

This makes it sometimes difficult to read the output(and it's ugly),
see: https://i.imgur.com/zhZkebc.png

Some of the translations should maybe be fixed in this case to make
them
shorter, but the alignment should probably be dynamic.

RHEL/Fedora[1] contains the python binding for libsmartcols, maybe
this
could be used to do the formating?

Not sure.  Is it readily available in other distributions and in
OpenEmbedded?


It's not in Debian (or Ubuntu) yet but I could package it for the next 
cycle. libsmartcols itself is part of util-linux.


For OpenEmbedded I don't know.


___
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] checkpolicy: Fix bug in handling type declaration in optional block.

[Dominick Grift]

On 01/18/2017 09:53 PM, James Carter wrote:
> Nicolas Iooss discovered that requiring a type in an optional block
> after the type has already been declared in another optional block
> results in a duplicate declaration error.
> 

from what i have been told and from experience, types cannot, reliably,
be declared in optional blocks.

if the above is true, then the compiler should not allow one to declare
a type in an optional block in the first place

> The following policy will trigger the error.
> 
> optional {
>   type T1;
> }
> 
> optional {
>   require { type T1; }
> }
> 
> In this case, although symtab_insert() in libsepol properly identifies
> that the first T1 is a declaration while the second is a require, it
> will return -2 which is the return value for a duplicate declaration
> and expect the calling code to properly handle the situation. The
> caller is require_symbol() in checkpolicy and it checks if the previous
> declaration is in the current scope. If it is, then the require can be
> ignored. It also checks to see if the declaration is a type and the
> require an attribute or vice versa which is an error. The problem is
> that -2 is returned if the declaration is not in scope which is
> interpreted as a duplicate declaration error.
> 
> The function should return 1 instead which means that they symbol was not
> added and needs to be freed later.
> 
> Signed-off-by: James Carter 
> ---
>  checkpolicy/module_compiler.c | 16 +++-
>  1 file changed, 3 insertions(+), 13 deletions(-)
> 
> diff --git a/checkpolicy/module_compiler.c b/checkpolicy/module_compiler.c
> index 6e5483c..bb60f34 100644
> --- a/checkpolicy/module_compiler.c
> +++ b/checkpolicy/module_compiler.c
> @@ -647,7 +647,6 @@ int require_symbol(uint32_t symbol_type,
>   } else if (retval == -2) {
>   /* ignore require statements if that symbol was
>* previously declared and is in current scope */
> - int prev_declaration_ok = 0;
>   if (is_id_in_scope(symbol_type, key)) {
>   if (symbol_type == SYM_TYPES) {
>   /* check that previous symbol has same
> @@ -661,23 +660,14 @@ int require_symbol(uint32_t symbol_type,
>   table, key);
>   assert(old_datum != NULL);
>   unsigned char old_isattr = old_datum->flavor;
> - prev_declaration_ok =
> - (old_isattr == new_isattr ? 1 : 0);
> - } else {
> - prev_declaration_ok = 1;
> + if (old_isattr != new_isattr)
> + return -2;
>   }
> - }
> - if (prev_declaration_ok) {
>   /* ignore this require statement because it
>* was already declared within my scope */
>   stack_top->require_given = 1;
> - return 1;
> - } else {
> - /* previous declaration was not in scope or
> -  * had a mismatched type/attribute, so
> -  * generate an error */
> - return -2;
>   }
> + return 1;
>   } else if (retval < 0) {
>   return -3;
>   } else {/* fall through possible if retval is 0 or 1 */
> 


-- 
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.

[PATCH] checkpolicy: Fix bug in handling type declaration in optional block.

[James Carter]

Nicolas Iooss discovered that requiring a type in an optional block
after the type has already been declared in another optional block
results in a duplicate declaration error.

The following policy will trigger the error.

optional {
  type T1;
}

optional {
  require { type T1; }
}

In this case, although symtab_insert() in libsepol properly identifies
that the first T1 is a declaration while the second is a require, it
will return -2 which is the return value for a duplicate declaration
and expect the calling code to properly handle the situation. The
caller is require_symbol() in checkpolicy and it checks if the previous
declaration is in the current scope. If it is, then the require can be
ignored. It also checks to see if the declaration is a type and the
require an attribute or vice versa which is an error. The problem is
that -2 is returned if the declaration is not in scope which is
interpreted as a duplicate declaration error.

The function should return 1 instead which means that they symbol was not
added and needs to be freed later.

Signed-off-by: James Carter 
---
 checkpolicy/module_compiler.c | 16 +++-
 1 file changed, 3 insertions(+), 13 deletions(-)

diff --git a/checkpolicy/module_compiler.c b/checkpolicy/module_compiler.c
index 6e5483c..bb60f34 100644
--- a/checkpolicy/module_compiler.c
+++ b/checkpolicy/module_compiler.c
@@ -647,7 +647,6 @@ int require_symbol(uint32_t symbol_type,
} else if (retval == -2) {
/* ignore require statements if that symbol was
 * previously declared and is in current scope */
-   int prev_declaration_ok = 0;
if (is_id_in_scope(symbol_type, key)) {
if (symbol_type == SYM_TYPES) {
/* check that previous symbol has same
@@ -661,23 +660,14 @@ int require_symbol(uint32_t symbol_type,
table, key);
assert(old_datum != NULL);
unsigned char old_isattr = old_datum->flavor;
-   prev_declaration_ok =
-   (old_isattr == new_isattr ? 1 : 0);
-   } else {
-   prev_declaration_ok = 1;
+   if (old_isattr != new_isattr)
+   return -2;
}
-   }
-   if (prev_declaration_ok) {
/* ignore this require statement because it
 * was already declared within my scope */
stack_top->require_given = 1;
-   return 1;
-   } else {
-   /* previous declaration was not in scope or
-* had a mismatched type/attribute, so
-* generate an error */
-   return -2;
}
+   return 1;
} else if (retval < 0) {
return -3;
} else {/* fall through possible if retval is 0 or 1 */
-- 
2.7.4

___
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: Has anyone ever looked into adding labeling support for the cgroup file system

[Daniel J Walsh]

I believe in the Tom Sawyer method of writing code.  Suggest a neat idea
and wait for some else to "Whitewash the fence"  ie write the patches.


On 01/18/2017 02:26 PM, Paul Moore wrote:
> On Tue, Jan 17, 2017 at 10:51 AM, Stephen Smalley  wrote:
>> On Tue, 2017-01-17 at 10:34 -0500, Daniel J Walsh wrote:
>>> In order to allow processes to modify the cgroup hierarchy in a
>>> container from an SELinux point of view, we need to allow read/write
>>> access to cgroup_t, which means that a container process could break
>>> out
>>> and modify all cgroups, we want to allow them to only modify the
>>> portion
>>> of the hierarchy handed to them.
>>>
>>> Would be a nice security improvement for docker.
>> Probably as easy as adding cgroup to the list of filesystem types that
>> use genfscon but also support setxattr (like sysfs) in
>> selinux_is_sblabel_mnt() in security/selinux/hooks.c.  sysfs and cgroup
>> are both implemented on top of kernfs in modern kernels, so they should
>> both support proper setting of security labels.
> .. and a test should be added to the selinux-testsuite.
>
> Come on Dan, you know you want to write some more kernel code ;)
>

___
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: Has anyone ever looked into adding labeling support for the cgroup file system

[Paul Moore]

On Tue, Jan 17, 2017 at 10:51 AM, Stephen Smalley  wrote:
> On Tue, 2017-01-17 at 10:34 -0500, Daniel J Walsh wrote:
>> In order to allow processes to modify the cgroup hierarchy in a
>> container from an SELinux point of view, we need to allow read/write
>> access to cgroup_t, which means that a container process could break
>> out
>> and modify all cgroups, we want to allow them to only modify the
>> portion
>> of the hierarchy handed to them.
>>
>> Would be a nice security improvement for docker.
>
> Probably as easy as adding cgroup to the list of filesystem types that
> use genfscon but also support setxattr (like sysfs) in
> selinux_is_sblabel_mnt() in security/selinux/hooks.c.  sysfs and cgroup
> are both implemented on top of kernfs in modern kernels, so they should
> both support proper setting of security labels.

... and a test should be added to the selinux-testsuite.

Come on Dan, you know you want to write some more kernel code ;)

-- 
paul moore
www.paul-moore.com
___
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.

[PATCH] Compilation fixes for macOS

[Karl MacMillan]

Compilation fixes for macOS

ln on macOS doesn't support --relative, so use the gnu version by default.

Changes to how PREFIX is used in recent Makefiles make it so that
installation to /usr/local is broken on all systems, but /usr is not
writable on recent macOS versions so that is needed. This patch makes
'PREFIX=/usr/local make install' work again, but will break the
default of having LIBDIR be /usr/lib and SHLIBDIR be /usr/lib. I'm not
certain what this might break.

---
 README| 3 +++
 libsepol/src/Makefile | 6 --
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/README b/README
index e6f7276..2e04fa6 100644
--- a/README
+++ b/README
@@ -14,6 +14,9 @@ make LIBDIR=/usr/lib64 SHLIBDIR=/lib64 install
install-pywrap relabel
 or on x86 (32-bit), run:
 make install install-pywrap relabel

+To install everyting under /usr/local run:
+make PREFIX=/usr/local install install-pywrap relabel
+
 This may render your system unusable if the upstream SELinux userspace
 lacks library functions or other dependencies relied upon by your
 distribution.  If it breaks, you get to keep both pieces.
diff --git a/libsepol/src/Makefile b/libsepol/src/Makefile
index 497cd56..1a924e1 100644
--- a/libsepol/src/Makefile
+++ b/libsepol/src/Makefile
@@ -2,7 +2,7 @@
 PREFIX ?= $(DESTDIR)/usr
 INCLUDEDIR ?= $(PREFIX)/include
 LIBDIR ?= $(PREFIX)/lib
-SHLIBDIR ?= $(DESTDIR)/lib
+SHLIBDIR ?= $(PREFIX)/lib
 RANLIB ?= ranlib
 LIBBASE ?= $(shell basename $(LIBDIR))
 CILDIR ?= ../cil
@@ -32,10 +32,12 @@ endif

 LD_SONAME_FLAGS=-soname,$(LIBSO),--version-script=$(LIBMAP),-z,defs

+LN=ln
 OS := $(shell uname)
 ifeq ($(OS), Darwin)
 LD_SONAME_FLAGS=-install_name,$(LIBSO)
 LDFLAGS += -undefined dynamic_lookup
+LN=gln
 endif

 all: $(LIBA) $(LIBSO) $(LIBPC)
@@ -84,7 +86,7 @@ install: all
install -m 755 $(LIBSO) $(SHLIBDIR)
test -d $(LIBDIR)/pkgconfig || install -m 755 -d $(LIBDIR)/pkgconfig
install -m 644 $(LIBPC) $(LIBDIR)/pkgconfig
-   ln -sf --relative $(SHLIBDIR)/$(LIBSO) $(LIBDIR)/$(TARGET)
+   $(LN) -sf --relative $(SHLIBDIR)/$(LIBSO) $(LIBDIR)/$(TARGET)

 relabel:
/sbin/restorecon $(SHLIBDIR)/$(LIBSO)
-- 
2.6.2
___
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: New Blog on how SELinux blocked Docker container escape.

[Daniel J Walsh]

On 01/18/2017 12:05 AM, 面和毅 wrote:
> Dear Sir,
>
> I'm member of Japan-SOSS SIG(Secure OSS Special
> Interest Group).
> We love SELinux(12years user) and we are promoting SELinux in Japan.
>
> >From technical interesting(we are promoting Docker
> with SELinux), we did PoC for CVE-2016-9962 on Fedora25.
>
> Then we found current SELinux(maybe policy) does not
> mitigate that vulnerability.
>
> We could reproduce that vulnerability with
> - add CAP_SYS_PTRACE to container
> - modified runc because there’s not so much race window on runc.
> then we think it's not so easy in usual situation.
> Also we couldn't reproduce it on CentOS7(latest).
>
> We posted that PoC result on our community blog.
> https://jsosug.github.io/post/omok-selinux-docker-20170118/
>
> Also we wish to argue how can we protect this kind of
> vulnerability by using SELinux.
>
> Kind Regards,
>
> OMO
Attempt to cat /etc/shadow in your test to see the blockage.

Here is a blog I wrote on the topic.

http://rhelblog.redhat.com/2017/01/13/selinux-mitigates-container-vulnerability/

___
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: New Blog on how SELinux blocked Docker container escape.

[Daniel J Walsh]

On 01/18/2017 12:05 AM, 面和毅 wrote:
> Dear Sir,
>
> I'm member of Japan-SOSS SIG(Secure OSS Special
> Interest Group).
> We love SELinux(12years user) and we are promoting SELinux in Japan.
>
> >From technical interesting(we are promoting Docker
> with SELinux), we did PoC for CVE-2016-9962 on Fedora25.
>
> Then we found current SELinux(maybe policy) does not
> mitigate that vulnerability.
>
> We could reproduce that vulnerability with
> - add CAP_SYS_PTRACE to container
> - modified runc because there’s not so much race window on runc.
> then we think it's not so easy in usual situation.
> Also we couldn't reproduce it on CentOS7(latest).
>
> We posted that PoC result on our community blog.
> https://jsosug.github.io/post/omok-selinux-docker-20170118/
>
> Also we wish to argue how can we protect this kind of
> vulnerability by using SELinux.
>
> Kind Regards,
>
> OMO
It mitigates the escape by controlling what can be written and most of
what can be read.
Currently policy allows for some information to be read off of the host
system since the idea
was to allow things like

docker run -ti -v /etc/passwd:/etc/passwd fedora sh

Content in /usr and some content in /etc allowed to be read from inside
of the container.  Content in /var, /home, /root or most other places
where people would store data are blocked.

To work.  I am tightening up the policy to remove the ability to read
content in /etc
___
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] checkpolicy: do not leak memory when declaring a type which has been required

[James Carter]

On 01/17/2017 04:47 PM, Stephen Smalley wrote:

On Sat, 2017-01-14 at 14:12 +0100, Nicolas Iooss wrote:

This kind of strange construction is currently accepted by
checkmodule
but it makes memory to be leaked in declare_type():

optional {
require { type TYPE1; }
}
optional {
require { attribute ATTR; }
type TYPE1, ATTR;
}

Moreover reversing the order of these two optional blocks leads to an
(expected) error:

ERROR 'duplicate declaration of type/attribute' at token 'TYPE1'
on line 14:
require { type TYPE1; }


I could be wrong, but this error seems wrong to me.  It isn't declaring
the type multiple times but instead is requiring it in one optional
block (with an empty body besides the require) and then declaring it in
another.  Technically, that should turn on the first optional block
during link/expand IIUC.  cc'ing some others



The error looks wrong to me as well.

Jim



Make checkmodule fails with an error when encourntering the first
construction.

Moreover the construction below also makes memory to be leaked:

optional {
require { type TYPE2; attribute ATTR; }
typeattribute TYPE2 ATTR;
}
type TYPE2;

This example is valid and is used by several refpolicy modules. In
declare_type(), declare_symbol() returns 1, stack_top->parent is NULL
and the scope of TYPE2 has been updated when declare_symbol() called
symtab_insert(). When these conditions are met, declare_type() should
return the currently existing type in the policy database.

Signed-off-by: Nicolas Iooss 
---

I have tested this patch both with "make test" and by compiling the
current master branch of refpolicy. I have not tested it to build any
Android policy.

 checkpolicy/module_compiler.c | 31 +--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/checkpolicy/module_compiler.c
b/checkpolicy/module_compiler.c
index 6e5483c17540..04d09d1445a3 100644
--- a/checkpolicy/module_compiler.c
+++ b/checkpolicy/module_compiler.c
@@ -308,7 +308,7 @@ role_datum_t *declare_role(unsigned char isattr)
 type_datum_t *declare_type(unsigned char primary, unsigned char
isattr)
 {
char *id;
-   type_datum_t *typdatum;
+   type_datum_t *typdatum, *old_datum;
int retval;
uint32_t value = 0;

@@ -335,10 +335,37 @@ type_datum_t *declare_type(unsigned char
primary, unsigned char isattr)
typdatum->flavor = isattr ? TYPE_ATTRIB : TYPE_TYPE;

retval = declare_symbol(SYM_TYPES, id, typdatum, ,
);
-   if (retval == 0 || retval == 1) {
+   if (retval == 0) {
if (typdatum->primary) {
typdatum->s.value = value;
}
+   } else if (retval == 1) {
+   /* the type has been previously marked as required
*/
+   assert(stack_top->type == 1);
+   if (stack_top->parent == NULL) {
+   /* in global scope, the type has previously
been required and is now declared.
+* policydbp->scope[SYM_TYPES] has been
updated by declare_symbol() */
+   old_datum = (type_datum_t *)
hashtab_search(policydbp->p_types.table, id);
+
+   /* check that previous symbol has the same
type/attribute-ness */
+   if (typdatum->flavor == old_datum->flavor) {
+   type_datum_destroy(typdatum);
+   free(typdatum);
+   typdatum = old_datum;
+   } else {
+   yyerror("declaration of
type/attribute with an unexpected flavor");
+   type_datum_destroy(typdatum);
+   free(typdatum);
+   typdatum = NULL;
+   }
+   free(id);
+   } else {
+   yyerror("declaration of type/attribute after
it has been required");
+   free(id);
+   type_datum_destroy(typdatum);
+   free(typdatum);
+   return NULL;
+   }
} else {
/* error occurred (can't have duplicate type
declarations) */
free(id);



--
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.