Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Fedora Development (http://www.linux-archive.org/fedora-development/)
-   -   Disabling selinux question (http://www.linux-archive.org/fedora-development/28164-disabling-selinux-question.html)

Linus Walleij 01-03-2008 09:21 PM

Disabling selinux question
 
Here's a spinoff relating to selinux from discussions around
system-config-services and its UI. selinux seem to involve the following
services/daemons:


auditd
mcstrans
restorecond
setroubleshoot

If I use system-config-selinux or anaconda to disable SELinux altogether,
then none of these are disabled accordingly. The only case seems to be
that auditd is turn on if I disable them all manually and then enable
SELinux.


Is this a bug or is there something I don't get here?

(I have a few similar issues with the services, but SELinux came up so
just taking the opportunity to ask.)


Linus

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Eric Paris 01-03-2008 09:34 PM

Disabling selinux question
 
On Thu, 2008-01-03 at 23:21 +0100, Linus Walleij wrote:
> Here's a spinoff relating to selinux from discussions around
> system-config-services and its UI. selinux seem to involve the following
> services/daemons:
>
> auditd

selinux uses auditd but they are not at all closely coupled. selinux
will function fine without auditd and auditd provides all of its
capabilities without selinux. There is no reason these 2 should be
coupled together.

> mcstrans
> restorecond
> setroubleshoot
>
> If I use system-config-selinux or anaconda to disable SELinux altogether,
> then none of these are disabled accordingly. The only case seems to be
> that auditd is turn on if I disable them all manually and then enable
> SELinux.

I don't think as a general rule that we couple services ever (maybe we
do and i just don't know it) but I don't think disabling your mta is
going to disable webmail. I however don't think it would be
unreasonable to file an anaconda bug and say that if selinux is disabled
the above 3 programs shouldn't be set to automatically start. If that
goes anywhere you could file against system-config-selinux (or vice
versa)

-Eric

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

John Dennis 01-03-2008 09:43 PM

Disabling selinux question
 
Linus Walleij wrote:
Here's a spinoff relating to selinux from discussions around
system-config-services and its UI. selinux seem to involve the following
services/daemons:


auditd
mcstrans
restorecond
setroubleshoot

If I use system-config-selinux or anaconda to disable SELinux
altogether, then none of these are disabled accordingly. The only case
seems to be that auditd is turn on if I disable them all manually and
then enable SELinux.


Is this a bug or is there something I don't get here?



auditd is the general auditing facility, SELinux messages are just one
of the possible auditing messages. You wouldn't want to disable auditing
just because SELinux was disabled, that would disable all auditing.


setroubleshootd is a diagnostic tool. If SELinux is completely disabled
the daemon exits if started.


Your expectation seems to be that if you disable SELinux it will
chkconfig off certain daemons. There is a distinction between having a
daemon started (e.g. chkconfig on) and whether it continues to run once
started. Allowing the daemon to decide if it should run or exit is more
robust than some utility which thinks it knows if something should be
chkconfig'ed on or not because it will almost certainly get that answer
wrong.



--
John Dennis <jdennis@redhat.com>

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Linus Walleij 01-04-2008 10:32 AM

Disabling selinux question
 
Eric and others, please be patient with me now, because I'm trying to
understand our implicit rationale surrounding the selinux services here,
I'm not ranting. I might very well be uneducated and stupid, but sometimes
(as has been said before) it is useful to take the perspective of a
newcomer to a certain system (or in my case subsystem) and try to
understand why this user has problems with it.


Now I have this problems with the services required by SELinux, a
setting which may have been default-disabled during install.


On Thu, 3 Jan 2008, Eric Paris wrote:


selinux uses auditd but they are not at all closely coupled. selinux
will function fine without auditd and auditd provides all of its
capabilities without selinux. There is no reason these 2 should be
coupled together.


I get it. (Did some homework reading up on auditd here.)

So every Fedora user must have these (right?):
root 2219 0.0 0.0 12288 684 ? S<sl 10:14 0:00 auditd
root 2221 0.0 0.0 12200 708 ? S<sl 10:14 0:00 /sbin/audispd

What else, besides selinux, is using auditd in Fedora right now or in the
immediate future? (Since we're a distribution we don't count theoretical
use cases I hope...)


bash-3.2$ repoquery --whatrequires `repoquery --provides audit`
setroubleshoot-server-0:2.0.0-3.fc9.noarch
audispd-plugins-0:1.6.4-3.fc9.i386
seedit-0:2.2.0-1.fc9.i386
amtu-0:1.0.6-1.fc9.i386
audit-0:1.6.4-3.fc9.i386

auditspd-plugins, seedit and amtu are not default-installed, so on a
Fedora default install, SELinux is really the only thing actually using
auditd, am I right?


If I read this correctly, we must have auditd running on any Fedora box
everywhere, even without SELinux since:


* auditspd-plugins may be installed and can monitor remote machines and
wouldn't work without auditd, so the entire network comes into the
picture here and it's hard for the UI to know what the user wants.

* amtu may be installed, so then it is necessary to have.

As indeed if the user of system-config-services or anaconda previously
disabled auditd, then installing the amtu or auditspd-plugins RPM will
or should turn the service on again by some %post script or similar,
right?


If this is NOT true, then the user should NOT be allowed to disable auditd
under any circumstances, and shouldn't worry about it using a few KB of
memory, it should have "# hide: true" added to /etc/init.d/auditd
so it's not even shown in s-c-s right?


There must be one of these things needing to have a bug filed.

I could easily imagine things like AppArmour, TOMOYO or tripwire (not
even in-kernel!) to use it in theory, though I don't know if they do in
practice, and none of them are in Fedora, so please enlighten me if you
know further use cases.


If from a users perspective A is only used by B and B is only used by A, I
think they should be coupled, really, because it helps the user.
system-config-* is for helping the user, and we're running a discussion on
system menus usability here in parallel to the SELinux rants, so Im trying
to think outside the RPM here ;)


As it stands now, a human can advise the user (in this case me) to turn
off auditd (and the other selinux services) on their travel laptop
"since it is not ever used on your config", but the system itself cannot.
That's good for sysadmin employment and bad for common users like me
who don't get it...



mcstrans
restorecond
setroubleshoot

If I use system-config-selinux or anaconda to disable SELinux altogether,
then none of these are disabled accordingly. The only case seems to be
that auditd is turn on if I disable them all manually and then enable
SELinux.


I don't think as a general rule that we couple services ever (maybe we
do and i just don't know it)


As I stated, since selinux requires auditd to be started, we already
couple "auditd ON" to "selinux ON".



but I don't think disabling your mta is
going to disable webmail.


? no ? why should it?

There is no golden rule here, but there are (IMHO) some cases where we
could help out managing services so that the defaults in
system-config-services is more understandable.



I however don't think it would be
unreasonable to file an anaconda bug and say that if selinux is disabled
the above 3 programs shouldn't be set to automatically start. If that
goes anywhere you could file against system-config-selinux (or vice
versa)


Okay!
https://bugzilla.redhat.com/show_bug.cgi?id=427506
(pending discussion as of whether auditd could actually be disabled too)

As I understand it, disabling auditd on some configs may be more important
though, because it actually sits there eating memory (well not much,
admittedly), it does not exit if it's not used by the system.


Linus

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Linus Walleij 01-04-2008 10:36 AM

Disabling selinux question
 
On Thu, 3 Jan 2008, John Dennis wrote:

auditd is the general auditing facility, SELinux messages are just one of the
possible auditing messages.


But on a Fedora default install SELinux is the only thing using and
requiring it, right?


setroubleshootd is a diagnostic tool. If SELinux is completely disabled the
daemon exits if started.


OK, should it have "# hide: true" in /etc/init.d/setroubleshootd so it
doesn't even turn up in system-config-services?


Allowing
the daemon to decide if it should run or exit is more robust than some
utility which thinks it knows if something should be chkconfig'ed on or not
because it will almost certainly get that answer wrong.


Then all these smart daemons should have "# hide : true" in their
respective /etc/init.d/foo script so avoid being managed by the smart
utility system-config-services, am I right?


Linus

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Steve Grubb 01-04-2008 12:58 PM

Disabling selinux question
 
On Friday 04 January 2008 06:32:27 Linus Walleij wrote:
> So every Fedora user must have these (right?):
> root 2219 0.0 0.0 12288 684 ? S<sl 10:14 0:00 auditd
> root 2221 0.0 0.0 12200 708 ? S<sl 10:14 0:00
> /sbin/audispd

You can turn it off if you want. :)


> What else, besides selinux, is using auditd in Fedora right now or in the
> immediate future? (Since we're a distribution we don't count theoretical
> use cases I hope...)

The audit logs are the collection point for all security relevant events from
failed logins, to avcs, to raw sockets being opened, to apps that segfault.
It collects everything that truly matters regarding security. It also has a
simple utility that gives you a quick overview of security events, aureport.
For an overview since Sunday, "aureport --start this-week"

Regarding the future, I have plans to add IDS/IPS plugin to audispd so that it
can spot and react to suspicious events. I also plan to create a prelude
plugin that can take events and send them to a prelude manager.

The security audit tool that was announced yesterday will send any security
issues it discovers to the audit system where it can be reported on. aide
also sends a summary description of what it finds to the audit system.

If auditd is not running, these events wind up in syslog. Some people do not
like all these events cluttering up syslog, so its simpler to just run the
audit daemon. Sooner or later people need to research something related to
security and the audit system has search and reporting tools.

> bash-3.2$ repoquery --whatrequires `repoquery --provides audit`
> setroubleshoot-server-0:2.0.0-3.fc9.noarch
> audispd-plugins-0:1.6.4-3.fc9.i386
> seedit-0:2.2.0-1.fc9.i386
> amtu-0:1.0.6-1.fc9.i386
> audit-0:1.6.4-3.fc9.i386
>
> auditspd-plugins, seedit and amtu are not default-installed, so on a
> Fedora default install, SELinux is really the only thing actually using
> auditd, am I right?

No, *everything* security related goes into the audit logs.


> If I read this correctly, we must have auditd running on any Fedora box
> everywhere, even without SELinux since:
>
> * auditspd-plugins may be installed and can monitor remote machines and
> wouldn't work without auditd, so the entire network comes into the
> picture here and it's hard for the UI to know what the user wants.
>
> * amtu may be installed, so then it is necessary to have.

Technically, amtu needs audit-libs. auditd just ensures amtu events windup in
audit logs rather than syslog. auditd should not be required by amtu.


> As indeed if the user of system-config-services or anaconda previously
> disabled auditd, then installing the amtu or auditspd-plugins RPM will
> or should turn the service on again by some %post script or similar,
> right?

It should not. amtu is happy to send things to audit system which sees that
auditd is not running and then forwards events to syslog for disposition.


> If this is NOT true, then the user should NOT be allowed to disable auditd
> under any circumstances, and shouldn't worry about it using a few KB of
> memory, it should have "# hide: true" added to /etc/init.d/auditd
> so it's not even shown in s-c-s right?
>
> There must be one of these things needing to have a bug filed.
>
> I could easily imagine things like AppArmour, TOMOYO or tripwire (not
> even in-kernel!) to use it in theory, though I don't know if they do in
> practice, and none of them are in Fedora, so please enlighten me if you
> know further use cases.

AppArmour does use the audit system. But we do not ship it. We have aide, not
tripwire and it is modified. TOMOYO, I'm not familiar with, nor have they
contacted me about reserving events. If you search on audit-libs, you will
see the real breadth of what uses the audit system. auditdis just the
collector, which may or may not be running or installed. All the apps need
the audit-libs to send events to the kernel which ultimately sends events to
the audit daemon.


> Okay!
> https://bugzilla.redhat.com/show_bug.cgi?id=427506
> (pending discussion as of whether auditd could actually be disabled too)

sigh...the services should exit if selinux is disabled. Its ok for them to
start up.

-Steve

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Enrico Scholz 01-04-2008 01:41 PM

Disabling selinux question
 
Steve Grubb <sgrubb@redhat.com> writes:

>> What else, besides selinux, is using auditd in Fedora right now or in
>> the immediate future? (Since we're a distribution we don't count
>> theoretical use cases I hope...)
>
> The audit logs are the collection point for all security relevant
> events from

that's a big problem with auditd: it supports only local logging and
logfiles on compromised machines are worthless... As 'auditd' "removes"
log messages like AVC errors from normal log sources they are not visible
for syslog anymore.

Hence, it's better to disable auditd and read the raw data on the remote
syslog server.



Enrico
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Steve Grubb 01-04-2008 02:00 PM

Disabling selinux question
 
On Friday 04 January 2008 09:41:58 Enrico Scholz wrote:
> >> What else, besides selinux, is using auditd in Fedora right now or in
> >> the immediate future? (Since we're a distribution we don't count
> >> theoretical use cases I hope...)
> >
> > The audit logs are the collection point for all security relevant
> > events from
>
> that's a big problem with auditd: it supports only local logging and
> logfiles on compromised machines are worthless...

Sure, I agree. There is a plugin for ZOS systems in rawhide that does remote
logging for the IBM RACF subsystem. I have also started a plugin that
transfers audit events off the machine to a central audit daemon. Its slow
going, but the pace of its development should pick up now.


> As 'auditd' "removes" log messages like AVC errors from normal log sources
> they are not visible for syslog anymore.

You can use the syslog plugin to wrap events back to syslog if you want them
there as well. Enable it in /etc/audisp/plugins.d/syslog.conf


> Hence, it's better to disable auditd and read the raw data on the remote
> syslog server.

Maybe at this point yes, but it will be changing as the plugins are developed.
If you do send events across via syslog, they won't be searchable unless you
duplicate a lot of ausearch/aureport from scratch.

-Steve

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

James Antill 01-04-2008 02:16 PM

Disabling selinux question
 
On Fri, 2008-01-04 at 12:36 +0100, Linus Walleij wrote:
> On Thu, 3 Jan 2008, John Dennis wrote:
>
> > auditd is the general auditing facility, SELinux messages are just one of the
> > possible auditing messages.
>
> But on a Fedora default install SELinux is the only thing using and
> requiring it, right?

No, think of it more like a different logging protocol. If you want to
get rid of "Yet another daemon" the best method would be to add audit
input support to the rsyslogd package.

> > setroubleshootd is a diagnostic tool. If SELinux is completely disabled the
> > daemon exits if started.
>
> OK, should it have "# hide: true" in /etc/init.d/setroubleshootd so it
> doesn't even turn up in system-config-services?
>
> > Allowing
> > the daemon to decide if it should run or exit is more robust than some
> > utility which thinks it knows if something should be chkconfig'ed on or not
> > because it will almost certainly get that answer wrong.
>
> Then all these smart daemons should have "# hide : true" in their
> respective /etc/init.d/foo script so avoid being managed by the smart
> utility system-config-services, am I right?

This means people can't stop the service, why do you want to do
that? Nothing "bad" happens if you stop any of these.

--
James Antill <james.antill@redhat.com>
Red Hat
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Eric Paris 01-04-2008 02:40 PM

Disabling selinux question
 
On Fri, 2008-01-04 at 12:32 +0100, Linus Walleij wrote:
> Eric and others, please be patient with me now, because I'm trying to
> understand our implicit rationale surrounding the selinux services here,
> I'm not ranting. I might very well be uneducated and stupid, but sometimes
> (as has been said before) it is useful to take the perspective of a
> newcomer to a certain system (or in my case subsystem) and try to
> understand why this user has problems with it.

Rant away, I've heard enough SELinux rants over the years *smile*

I just hope that every rant I hear from now on comes from someone who
tried SELinux on F8!

>
> On Thu, 3 Jan 2008, Eric Paris wrote:
>
> > selinux uses auditd but they are not at all closely coupled. selinux
> > will function fine without auditd and auditd provides all of its
> > capabilities without selinux. There is no reason these 2 should be
> > coupled together.
>
> I get it. (Did some homework reading up on auditd here.)
>
> So every Fedora user must have these (right?):
> root 2219 0.0 0.0 12288 684 ? S<sl 10:14 0:00 auditd
> root 2221 0.0 0.0 12200 708 ? S<sl 10:14 0:00 /sbin/audispd
>
> What else, besides selinux, is using auditd in Fedora right now or in the
> immediate future? (Since we're a distribution we don't count theoretical
> use cases I hope...)
>
> bash-3.2$ repoquery --whatrequires `repoquery --provides audit`
> setroubleshoot-server-0:2.0.0-3.fc9.noarch
> audispd-plugins-0:1.6.4-3.fc9.i386
> seedit-0:2.2.0-1.fc9.i386
> amtu-0:1.0.6-1.fc9.i386
> audit-0:1.6.4-3.fc9.i386
>

you didn't talk about 'audit'

the audit subsystem is a freestanding subsystem with lots of
capabilities and functionality of its own. By default, without any of
those packages installed audit is still going to get messages like user
login, segfaulting programs, changes of nics to promiscuous, and other
information. Audit can be used free standing to audit events on your
system, see man auditctl

There is no reason that a user cannot turn auditd off themselves (kernel
just reroutes the messages to syslog rather than audit log) but audit
still functions and serves a purpose all by itself.

My opinion, if you disable SELinux in the installer (or s-c-selinux) it
should disable those other programs you mentioned if those programs are
not smart enough to not run on their own. (sounds like setroubleshoot
and i'm going to guess sealert already are smart enough and
anaconda/s-c-* shouldn't bother them...)

-Eric

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list


All times are GMT. The time now is 09:51 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.