All of lore.kernel.org
 help / color / mirror / Atom feed
From: Victor Porton <porton@narod.ru>
To: SELinux <selinux@tycho.nsa.gov>
Subject: Refactor installation of policies and modules
Date: Fri, 09 May 2014 21:19:04 +0300	[thread overview]
Message-ID: <3092401399659544@web23g.yandex.ru> (raw)

Consider the following use case (we may specify that it runs on a Debian system).

First we need to create a base (entirely permissive) policy for Debian, because the default Debian policy is buggy or may be unwanted in any other reason (as for performance).

Suppose then I install and configure this permissive policy.

The next thing I want, is to create a "sandbox" Debian package which installs its own SELinux module. Sandbox should allow running programs with limited filesystem and network access as for usage of untrusted programs downloaded from the Web. It is required for a real project: http://freesoft.portonvictor.org/namespaces.xml (which I may implement as a proxy server which uses the "sandbox" binary from "sandbox" package, probably and/or as a command line program).

Next, suppose I decide that the default policy is no more buggy and switch the policy.

What does happen in this case? A disaster! The "sandbox" module installed for the permissive policy is not installed for the default policy. So "sandbox" may not work and allow access of untrusted programs to my files.

^^ This is the first trouble.

The second trouble is known to all of you: When we edit /etc/selinux/config the attributes of the filesystem are not updated automatically.

My proposed solution follows. The solution requires refactoring of SELinux policies and modules installation, but it is certainly a job worth to do.

Manual editing of /etc/selinux/config should be deprecated.

Instead there should be a command which:

- allows to choose a policy from several installed policies (and also to enable/disable SELinux).

- when it is requested to change a policy, it should be recompiled with all installed SELinux modules. If compilation fails, the policy should not be changed (a security requirement!) (this may require compilation into a temporary directory before actual installation of the modules)

When installed, non-base modules should be kept say in /etc/selinux/modules/ so that they could be reinstalled when switching policy.

An other benefit of editing the configuration such as /etc/selinux/config only with a special command, is that the FS can be automatically relabeled when policy is switched or enabled after being disabled.

Please take my proposal seriously:

- It is a real-life trouble which needs to be solved (in Debian and other systems).

- It is a security threat. Think seriously about sandbox suddenly allowing any actions to a program downloaded from the Web!

I may or may not work on this refactoring myself: I am not a system programmer, but I am willing to work for this project.

P.S. I may probably develop the above mentioned permissive policy for Debian, as I can't work with buggy default policy. Then I want to invest my goodness into creating a robust sandbox.

--
Victor Porton - http://portonvictor.org

             reply	other threads:[~2014-05-09 18:19 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-09 18:19 Victor Porton [this message]
2014-05-10 12:00 ` Refactor installation of policies and modules Sven Vermeulen

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=3092401399659544@web23g.yandex.ru \
    --to=porton@narod.ru \
    --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.