not installing SELinux with Fedora

Hi folks,

Controlling SELinux, Fedora Core 3 SELinux FAQ at
http://fedora.redhat.com/docs/selinux-faq-fc3/
says:

"Q: How do I install/not install SELinux?" 

"A: The installer handles this based on the choice
 you make in the Firewall Configuration screen. The
 default running policy is the targeted policy, and
 it is on by default."

Doesn't this beg the question? In fact, doesn't the
Firewall Configuration screen merely determine whether
SELinux is enabled/disabled?

Users of Fedora Core 4 want to know, how do we not,
repeat not, install SELinux?

Yours truly
STEWART & CIE.

Steve Stewart

[Steve G]

> Users of Fedora Core 4 want to know, how do we not,
> repeat not, install SELinux? 
Why would you want to do that? Its better to fix problems than avoid them.

SE Linux has to be installed. libselinux is linked to many apps and the KERNEL is
compiled with support for SE Linux. You can disable it, but you have to install
it.

-Steve Grubb

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

[Daniel J Walsh]

Steve G wrote:

> >Users of Fedora Core 4 want to know, how do we not,
> >repeat not, install SELinux?
> >    
> >
>
> Why would you want to do that? Its better to fix problems than avoid them.
>
> SE Linux has to be installed. libselinux is linked to many apps and the KERNEL is
> compiled with support for SE Linux. You can disable it, but you have to install
> it.
>
> -Steve Grubb
>   
>  
You can choose in the installer to not install with SELinux.  This will 
eliminate most of the SELinux packages and not label the file system.

If you later choose to run with selinux you could install the packages 
and relabel the file system.

> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
>
> --
> fedora-selinux-list mailing list
> fedora-selinux-list(a)redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-selinux-list
>   
>  

--

[Christofer C. Bell]

On 6/9/05, stewartetcie(a)canada.com <stewartetcie(a)canada.com&gt; wrote:
>  Users of Fedora Core 4 want to know, how do we not,
>  repeat not, install SELinux? 
Since you're already familiar how to disable SELinux, the short answer
to your question is, "you can't."

-- 
Chris

"With the way things are starting to go in this country, if forced to
choose between being caught with a van full of pirated DVDs or heroin
you'd actually have to pause and think about it." -- Michael Bell,
drunkenblog.com

[Stephen Smalley]

On Thu, 2005-06-16 at 02:43 -0500, Christofer C. Bell wrote:
>  On 6/9/05, stewartetcie(a)canada.com <stewartetcie(a)canada.com&gt;
> wrote:
>  >
>  > Users of Fedora Core 4 want to know, how do we not,
>  > repeat not, install SELinux?
>  
>  Since you're already familiar how to disable SELinux, the short answer
>  to your question is, "you can't." 
And just to be clear, disabling SELinux truly does cause SELinux to
unhook itself from the kernel's security framework, so that it is no
longer called by the kernel.  And the userspace SELinux code is
bracketed by checks of whether SELinux is enabled in the kernel, so it
also ceases to be executed when you disable SELinux in the kernel.

-- 
Stephen Smalley
National Security Agency

New Policy Doesn't Fix It

[Daniel Normolle]

Hello, All,

I am running kernel 2.6.11-1.27_FC3.  I had disabled SELinux two
policies ago because it caused two applications I depend on,
Open Office and SAS, from launching.  I relabeled the disk, turned
SELinux back on, and updated with today's new, improved policy.
My situation is unchanged,  launching SAS generates this message:

Jun 16 12:50:49 kernel: audit(1118940649.944:0): avc:  denied  { execmod 
} for  pid=5124 comm=sas path=/usr/local/SAS/SAS_9.1/sasexe/saswzx 
dev=dm-0 ino=5134594 scontext=user_u:system_r:unconfined_t 
tcontext=root:object_r:usr_t tclass=file

Launching open office generates this message:

Jun 16 12:51:01 kernel: audit(1118940661.113:0): avc:  denied  { execmod 
} for  pid=5152 comm=soffice.bin 
path=/opt/openoffice.org1.9.104/program/libicudata.so.26.0.1 dev=dm-0 
ino=4728657 scontext=user_u:system_r:unconfined_t 
tcontext=system_u:object_r:usr_t tclass=file

Please let me know if you have sage advice or further questions.  Be
specific, SELinux is the NEW WORLD for me.

Regards, dpn

New Policy Doesn't Fix It

[Daniel J Walsh]

Daniel Normolle wrote:

>  Hello, All,
>
>  I am running kernel 2.6.11-1.27_FC3.  I had disabled SELinux two
>  policies ago because it caused two applications I depend on,
>  Open Office and SAS, from launching.  I relabeled the disk, turned
>  SELinux back on, and updated with today's new, improved policy.
>  My situation is unchanged,  launching SAS generates this message:
>
>  Jun 16 12:50:49 kernel: audit(1118940649.944:0): avc:  denied  { 
>  execmod } for  pid=5124 comm=sas 
>  path=/usr/local/SAS/SAS_9.1/sasexe/saswzx dev=dm-0 ino=5134594 
>  scontext=user_u:system_r:unconfined_t tcontext=root:object_r:usr_t 
>  tclass=file
>
>  Launching open office generates this message:
>
>  Jun 16 12:51:01 kernel: audit(1118940661.113:0): avc:  denied  { 
>  execmod } for  pid=5152 comm=soffice.bin 
>  path=/opt/openoffice.org1.9.104/program/libicudata.so.26.0.1 dev=dm-0 
>  ino=4728657 scontext=user_u:system_r:unconfined_t 
>  tcontext=system_u:object_r:usr_t tclass=file
>
>  Please let me know if you have sage advice or further questions.  Be
>  specific, SELinux is the NEW WORLD for me.
>
>  Regards, dpn
>
>  -- 
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  http://www.redhat.com/mailman/listinfo/fedora-selinux-list 
Are you sure you have allow_execmod set?

setsebool -P allow_execmod=1

--

New Policy Doesn't Fix It

[Stephen Smalley]

On Fri, 2005-06-17 at 06:58 -0400, Daniel J Walsh wrote:
>  Are you sure you have allow_execmod set?
>  
>  setsebool -P allow_execmod=1 
Per the avc message, the file was labeled usr_t
(/opt/openoffice.org1.9.104/program/libicudata.so.26.0.1).  So unless
you are allowing execmod to all file types (not a good idea), that
wouldn't help.  It would need to be texrel_shlib_t (preferably) or at
least shlib_t (not sure what you allow in targeted policy).

-- 
Stephen Smalley
National Security Agency

New Policy Doesn't Fix It

[Colin Walters]

On Fri, 2005-06-17 at 07:40 -0400, Stephen Smalley wrote:
>  On Fri, 2005-06-17 at 06:58 -0400, Daniel J Walsh wrote:
>  > Are you sure you have allow_execmod set?
>  > 
>  > setsebool -P allow_execmod=1
>  
>  Per the avc message, the file was labeled usr_t
>  (/opt/openoffice.org1.9.104/program/libicudata.so.26.0.1).  So unless
>  you are allowing execmod to all file types (not a good idea),  
For the targeted policy I think we need do need to allow it for
file_type.  The original security goal of the targeted policy was that
only a few specific services were confined.  We expect Fedora server
administrators to understand SELinux and read documentation about how to
secure their services using it.  We cannot expect the same of all of the
many other kinds of people using Fedora; in this particular case, it
looks to me like Daniel is a free software enthusiast tracking the
latest upstream releases of OpenOffice.org.  Until we can have some
reasonable expectation of ISV software installers labelling data
correctly, I don't think we can use execmod/execmem for unconfined_t at
all.

New Policy Doesn't Fix It

[Stephen Smalley]

On Fri, 2005-06-17 at 07:52 -0400, Colin Walters wrote:
>  For the targeted policy I think we need do need to allow it for
>  file_type.  The original security goal of the targeted policy was that
>  only a few specific services were confined.  We expect Fedora server
>  administrators to understand SELinux and read documentation about how to
>  secure their services using it.  We cannot expect the same of all of the
>  many other kinds of people using Fedora; in this particular case, it
>  looks to me like Daniel is a free software enthusiast tracking the
>  latest upstream releases of OpenOffice.org.  Until we can have some
>  reasonable expectation of ISV software installers labelling data
>  correctly, I don't think we can use execmod/execmem for unconfined_t at
>  all. 
Hmm...well, if so, please limit to the targeted/domains/unconfined.te
file and don't alter the unconfined_domain() macro.  Looks like you are
already allowing execmod to a variety of types in the targeted
unconfined.te, but not to all file types.

Given the permissive nature of targeted policy (e.g. boolean defaults
for apache and execmem/execmod are permissive), I think the release
notes or SELinux FAQ should in the future give instructions on how to
tighten up the settings for admins who want to do so.  Otherwise, they
aren't likely to even think about it.

  
-- 
Stephen Smalley
National Security Agency

New Policy Doesn't Fix It

[Colin Walters]

On Fri, 2005-06-17 at 08:03 -0400, Stephen Smalley wrote:

>  Hmm...well, if so, please limit to the
> targeted/domains/unconfined.te
>  file and don't alter the unconfined_domain() macro.  Looks like you are
>  already allowing execmod to a variety of types in the targeted
>  unconfined.te, but not to all file types. 
We also need to do so for initrc_t at least, because that is now the
domain that services run under by default in FC4.  It would be nice
though if we could go back to using unconfined_t there, but it seems
complicated.  Could we do something like:

domain_auto_trans(initrc_t, exec_type - targeted_exec_type, unconfined_t) 

Would need to give e.g. httpd_exec_t the targeted_exec_type attribute,
and I'm not sure attribute subtraction works.

>  Given the permissive nature of targeted policy (e.g. boolean
> defaults
>  for apache and execmem/execmod are permissive), I think the release
>  notes or SELinux FAQ should in the future give instructions on how to
>  tighten up the settings for admins who want to do so.  Otherwise, they
>  aren't likely to even think about it. 
Absolutely, this would make a good entry in the FAQ.  Although I'd
personally really like to see a Fedora security guide, these booleans
would me mentioned there too.