All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel J Walsh <dwalsh@redhat.com>
To: "Christopher J. PeBenito" <cpebenito@tresys.com>
Cc: Stephen Smalley <sds@tycho.nsa.gov>,
	James Morris <jmorris@namei.org>, Ken YANG <spng.yang@gmail.com>,
	SELinux List <selinux@tycho.nsa.gov>
Subject: Re: can not boot with strict policy
Date: Tue, 24 Apr 2007 09:08:48 -0400	[thread overview]
Message-ID: <462E0160.8090906@redhat.com> (raw)
In-Reply-To: <1177417417.8672.25.camel@sgc>

Christopher J. PeBenito wrote:
> On Mon, 2007-04-23 at 14:14 -0400, Daniel J Walsh wrote:
>   
>> So the real question, is there much value with the division between 
>> lib_t and shlib_t.
>> When dealing with strict policy, shared libraries were always getting 
>> mislabeled as lib_t, and causing problems, for little security advantage. 
>>     
>
> In Gentoo I don't see these kinds of problems, and we still have the
> strict policy as the default option (until recently on desktops) and I
> don't see this problem; the fc regexes work very well.  However, the
> Gentoo community is far smaller than Fedora/RHEL.
>
>   
The problems happen when people use tools like cp/tar and other tools to 
put libraries on the system.  So the question I put out is the value of 
being able to stop mmap a non shared library, give you a security 
benefit, versus the hassle of a denial, because of a mislabeled shared 
library.
I look at this the same way as bin_t/sbin_t, it might have made sense 
theoretically but in practice it added little/no security value.
>> As we remove the differences between strict and targeted, I don't intend 
>> to get rid of lib_t == shlib_t.
>>     
>
> I had intended to drop the alias, so i guess we need more discussion. :)
>
>   


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

  parent reply	other threads:[~2007-04-24 13:08 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-23 12:09 can not boot with strict policy Ken YANG
2007-04-23 15:01 ` Stephen Smalley
2007-04-23 17:42   ` James Morris
2007-04-23 17:48     ` Stephen Smalley
2007-04-23 18:14       ` Daniel J Walsh
2007-04-24  8:11         ` Ken YANG
2007-04-24 12:23           ` Daniel J Walsh
2007-04-24 12:26           ` Christopher J. PeBenito
2007-04-25 12:19             ` Ken YANG
2007-04-24 12:23         ` Christopher J. PeBenito
2007-04-24 12:59           ` Stephen Smalley
2007-04-24 13:08           ` Daniel J Walsh [this message]
2007-04-26  6:45     ` Russell Coker
2007-04-27 10:48       ` Ken YANG
2007-04-24  7:10 ` Russell Coker

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=462E0160.8090906@redhat.com \
    --to=dwalsh@redhat.com \
    --cc=cpebenito@tresys.com \
    --cc=jmorris@namei.org \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@tycho.nsa.gov \
    --cc=spng.yang@gmail.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.