Re: [PATCH 8/9] semanage: Update semanage to allow runtime labeling of ibendports

2017-05-14 Thread Jason Zaman 
On Tue, May 09, 2017 at 11:50:41PM +0300, Dan Jurgens wrote:
> From: Daniel Jurgens 
> 
> Update libsepol and libsemanage to work with ibendport records. Add local
> storage for new and modified ibendport records in ibendports.local.
> Update semanage to parse the ibendport command options to add, modify,
> and delete them.
> 
> Signed-off-by: Daniel Jurgens 
> ---
>  libsemanage/include/semanage/ibendport_record.h  |   62 +
>  libsemanage/include/semanage/ibendports_local.h  |   36 +++
>  libsemanage/include/semanage/ibendports_policy.h |   28 ++
>  libsemanage/include/semanage/semanage.h  |3 +
>  libsemanage/src/direct_api.c |   42 +++-
>  libsemanage/src/handle.h |   38 ++-
>  libsemanage/src/ibendport_internal.h |   48 
>  libsemanage/src/ibendport_record.c   |  154 +++
>  libsemanage/src/ibendports_file.c|  157 +++
>  libsemanage/src/ibendports_local.c   |  153 +++
>  libsemanage/src/ibendports_policy.c  |   55 
>  libsemanage/src/ibendports_policydb.c|   62 +
>  libsemanage/src/libsemanage.map  |1 +
>  libsemanage/src/policy_components.c  |4 +
>  libsemanage/src/semanage_store.c |1 +
>  libsemanage/src/semanage_store.h |1 +
>  libsemanage/src/semanageswig.i   |3 +
>  libsemanage/src/semanageswig_python.i|   43 +++
>  libsemanage/utils/semanage_migrate_store |3 +-
>  libsepol/include/sepol/ibendport_record.h|   68 +
>  libsepol/include/sepol/ibendports.h  |   45 
>  libsepol/include/sepol/sepol.h   |2 +
>  libsepol/src/ibendport_internal.h|   20 ++
>  libsepol/src/ibendport_record.c  |  299 
> ++
>  libsepol/src/ibendports.c|  255 ++
>  python/semanage/semanage |   58 -
>  python/semanage/seobject.py  |  238 +
>  27 files changed, 1857 insertions(+), 22 deletions(-)
>  create mode 100644 libsemanage/include/semanage/ibendport_record.h
>  create mode 100644 libsemanage/include/semanage/ibendports_local.h
>  create mode 100644 libsemanage/include/semanage/ibendports_policy.h
>  create mode 100644 libsemanage/src/ibendport_internal.h
>  create mode 100644 libsemanage/src/ibendport_record.c
>  create mode 100644 libsemanage/src/ibendports_file.c
>  create mode 100644 libsemanage/src/ibendports_local.c
>  create mode 100644 libsemanage/src/ibendports_policy.c
>  create mode 100644 libsemanage/src/ibendports_policydb.c
>  create mode 100644 libsepol/include/sepol/ibendport_record.h
>  create mode 100644 libsepol/include/sepol/ibendports.h
>  create mode 100644 libsepol/src/ibendport_internal.h
>  create mode 100644 libsepol/src/ibendport_record.c
>  create mode 100644 libsepol/src/ibendports.c

[ ... ]

> diff --git a/python/semanage/semanage b/python/semanage/semanage
> index 11b56e2..313537c 100644
> --- a/python/semanage/semanage
> +++ b/python/semanage/semanage
> @@ -61,6 +61,9 @@ usage_port_dict = {' --add': ('-t TYPE', '-p PROTOCOL', '-r 
> RANGE', '(', 'port_n
>  usage_ibpkey = "semanage ibpkey [-h] [-n] [-N] [-s STORE] ["
>  usage_ibpkey_dict = {' --add': ('-t TYPE', '-x SUBNET_PREFIX', '-r RANGE', 
> '(', 'ibpkey_name', '|', 'pkey_range', ')'), ' --modify': ('-t TYPE', '-x 
> SUBNET_PREFIX', '-r RANGE', '(', 'ibpkey_name', '|', 'pkey_range', ')'), ' 
> --delete': ('-x SUBNET_PREFIX', '(', 'ibpkey_name', '|', 'pkey_range', ')'), 
> ' --list': ('-C',), ' --extract': ('',), ' --deleteall': ('',)}
>  
> +usage_ibendport = "semanage ibendport [-h] [-n] [-N] [-s STORE] ["
> +usage_ibendport_dict = {' --add': ('-t TYPE', '-z IBDEV_NAME', '-r RANGE', 
> '(', 'port', ')'), ' --modify': ('-t TYPE', '-z IBDEV_NAME', '-r RANGE', '(', 
> 'port', ')'), ' --delete': ('-z IBDEV_NAME', '-r RANGE''(', 'port', ')'), ' 
> --list': ('-C',), ' --extract': ('',), ' --deleteall': ('',)}
> +
>  usage_node = "semanage node [-h] [-n] [-N] [-S STORE] ["
>  usage_node_dict = {' --add': ('-M NETMASK', '-p PROTOCOL', '-t TYPE', '-r 
> RANGE', 'node'), ' --modify': ('-M NETMASK', '-p PROTOCOL', '-t TYPE', '-r 
> RANGE', 'node'), ' --delete': ('-M NETMASK', '-p PROTOCOL', 'node'), ' 
> --list': ('-C',), ' --extract': ('',), ' --deleteall': ('',)}
>  
> @@ -152,6 +155,10 @@ def ibpkey_ini():
>  OBJECT = seobject.ibpkeyRecords(store)
>  return OBJECT
>  
> +def ibendport_ini():
> +OBJECT = seobject.ibendportRecords(store)
> +return OBJECT
> +
>  def module_ini():
>  OBJECT = seobject.moduleRecords(store)
>  return OBJECT
> @@ -187,8 +194,7 @@ def dontaudit_ini():
>  return OBJECT
>  
>  # define dictonary for seobject OBEJCTS
> -object_dict = {'login': login_ini, 'user':

Re: Why does Python want to read /proc/meminfo

2017-05-14 Thread Daniel Walsh 

On 05/06/2017 12:54 AM, Ian Pilcher wrote:

I am trying to write an SELinux policy to confine a simple service that
I have written in Python, and I'm trying to decide whether to allow or
dontaudit various denials.

To start, I've reduced my service to the simplest case:

  #!/usr/bin/python

  import sys

  sys.exit()

Running this program in a confined domain generated the following
denial:

avc:  denied  { read } for  pid=2024 comm="denatc" name="meminfo" 
dev="proc" ino=4026532028 scontext=system_u:system_r:denatc_t:s0 
tcontext=system_u:object_r:proc_t:s0 tclass=file


The program does continue on and exit cleanly, so it doesn't seem to
strictly require the access.

Does anyone know why Python is trying to access this file, or what
functionality I might be missing if I don't allow the access?

Usually tools read /proc/meminfo to figure out how much memory is 
available on the system and then to make some assumption about how much 
memory they can use.  A tool might allocate a memory buffer as X% of 
total memory on the system. (This is a bad assumption, since cgroups 
could alter the total amount of memory availabel to the process, but 
/proc/meminfo does not reflect the amount of memory available in the 
cgroup).  The code that looks at /proc/meminfo might be builtin to 
libc,  I would figure that whatever is trying to read /proc/meminfo 
expects to fail in certain situations, so it falls back to an alternate 
code path. This is most likely what you are seeing.



In most situations reading /proc/meminfo would not be considered a 
security risk, especially considering in the case of Cgroups the kernel 
will LIE.  :^)