All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Timothée Ravier" <siosm99@gmail.com>
To: Daniel J Walsh <dwalsh@redhat.com>,
	Stephen Smalley <sds@tycho.nsa.gov>,
	Steve Lawrence <slawrence@tresys.com>
Cc: SELinux <selinux@tycho.nsa.gov>
Subject: Re: Been looking at further shrinkage of the SELinux footprint on Linux.
Date: Thu, 07 Nov 2013 00:34:22 +0100	[thread overview]
Message-ID: <527AD1FE.9040200@gmail.com> (raw)
In-Reply-To: <5272A6ED.1000504@redhat.com>

On 31/10/2013 19:52, Daniel J Walsh wrote:
> On 10/31/2013 08:56 AM, Stephen Smalley wrote:
>> I guess the question is what behavior is desired here.  If you remove the
>> type itself, then these days it will get treated as unlabeled (so it 
>> becomes inaccessible to anything that doesn't have permissions to 
>> unlabeled, but that shouldn't be an issue for unconfined users) and if 
>> someone later re-installs the package/policy, then it should get remapped
>> to its original context due to the deferred context mapping support.  Is
>> that sufficient?  If not, then my proposed approach above of pushing all of
>> the file type declarations into a single module (probably the base module)
>> and never removing them would allow the types to always remain valid but
>> they'd still be inaccessible except to domains that are allowed access to
>> file_type (e.g. unconfined) when you remove the modules defining the allow
>> rules.  Is that sufficient?  If not, then your approach of never removing
>> modules will work but seems the least optimal to me.
> 
> Well I like the idea of defining alias for modules when they are not
> installed.  The biggest problem I see is around executables and potentially
> readable content.  If I install a package that labels something as
> foobar_exec_t and leaves the content on uninstall, a confined domain that was
> able to execute foobar_exec_t will now not be able to execute unlabeled_t.
> 
> If we could alias foobar_exec_t to bin_t when foobar.pp is not installed, then
> we get a little closer to the default, and I don;t have restorecon -R -v
> fixing unlabeled_t files.
> 
> similarly  foobar_usr content to -> usr_t, and foobar_etc_t to etc_t
> foobar_var_t -> var_t ...

Hi,

I'm afraid this would cause undesired and unexpected "un-confining" of
programs / content that used to be confined which could lead to
information leaks for example.

Are programs needing access to data from an uninstalled packages
something that does effectively happen ? Requiring a custom policy to
allow such corner cases does not feel excessive here.

Moreover, changing the labels to some other valid ones may confuse the
admin/user more than if files were to be kept with their original labels
(if all the types are kept available at all times) or if the labels are
set to unlabeled_t which is explicitly telling what happened.

Cheers,

Tim

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

  reply	other threads:[~2013-11-06 23:34 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-30 19:31 Been looking at further shrinkage of the SELinux footprint on Linux Daniel J Walsh
2013-10-30 19:42 ` Joshua Brindle
2013-10-30 20:14 ` Stephen Smalley
2013-10-30 20:36   ` Daniel J Walsh
2013-10-30 20:43     ` Stephen Smalley
2013-10-30 20:47       ` Stephen Smalley
2013-10-31 12:43         ` Steve Lawrence
2013-10-31 12:56           ` Stephen Smalley
2013-10-31 18:52             ` Daniel J Walsh
2013-11-06 23:34               ` Timothée Ravier [this message]
2013-10-31 18:48           ` Daniel J Walsh
2013-11-02 16:42     ` Sven Vermeulen
2013-11-02 18:09       ` Casey Schaufler
2013-11-02 21:18         ` Joshua Brindle
2013-11-04 14:42       ` Daniel J Walsh
2013-11-06 15:35         ` Sven Vermeulen
2013-11-06 15:40           ` Daniel J Walsh
2013-10-30 22:01 ` Colin Walters
2013-10-31 11:30   ` Stephen Smalley
2013-10-30 23:54 ` Colin Walters
2013-10-31 18:27   ` Daniel J Walsh

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=527AD1FE.9040200@gmail.com \
    --to=siosm99@gmail.com \
    --cc=dwalsh@redhat.com \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@tycho.nsa.gov \
    --cc=slawrence@tresys.com \
    /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.