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
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`
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,
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...
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
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
(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.
fedora-devel-list mailing list