Am Mittwoch, 28. Dezember 2011 schrieb Cristian Rodríguez:
On 28/12/11 20:54, Christian Boltz wrote:
Am Mittwoch, 28. Dezember 2011 schrieb Cristian
On 28/12/11 16:01, Per Jessen wrote:
Cristian Rodríguez wrote:
following, create a program that is able to figure out
what exactly init scripts do,
It already exists and is called /bin/bash -x
(I know that this probably isn't the answer you wanted to hear ;-)
Of course Im not talking about that.
(nice to see that you skip the more interesting questions. I would
really like to hear something about your /dev/brain interface...)
(temp)file usage is easy. That's something aa-genprof
(and in general, AppArmor in learning mode) can do easily.
Will it catch all sorts of bugs ? like writting directly to /tmp
without using mktemp or using sed with output to /tmp/namedfile ?
It will give you a list of files, and what was done with them (read,
write, exec etc.). If you re-run the initscript and get the same set of
tempfile names, then something smells very fishy ;-)
I know systemd supports "private /tmp" (IIRC as in "a private subdir of
/tmp that looks like /tmp itsself to the process"), and yes, that's a
good feature and adds some security.
But unfortunately there are some things that _need_ the shared /tmp for
some reason (for sockets etc.)
And there could also be attackers who inject files in a "private"
/tmp/*/ directory after it has been created. In other words, even with
private /tmp/*/ directories, you _still need to write secure programs_.
Obviously there is no automatism that can catch _all_ sort of bugs -
otherwise the security team would have been fired years ago (and we all
know they still have enough work) ;-)
works for starting daemons, and I agree that they
should provide proper exit status codes.
OTOH, I already explained some days ago that in some cases (like
AppArmor) ExecStatus would really make sense because there is no
daemon/process you can check.
I still don't get it, what do you want to do, that cannot be done
already with ExecStart ?
did you read the documentation ?
Yes, I did.
To come back
to systemd and AppArmor:
Yes, I can of course start a watchdog daemon in ExecStart that
(after loading the profiles) runs aa-status every 10 seconds and
errors out if something goes wrong. And I really would check
every 10 seconds so that everybody running "systemctl status"
gets an (at least nearly) up-to- date result.
Or I could use the ExecStatus "hook" in the service file, which
could then run aa-status when someone runs "systemctl status".
Now please tell me which way is smarter ;-)
Let me get this straight.
- Apparmor is security software, which people depends to secure their
systems, but does not provide any meaningful way to know it is loaded
? I expect something like this, especially if we are talking about
It does provide a way to check the status - but not in the way systemd
There is nothing like a process or a pid file (both wouldn't make any
Instead, the "aa-status" script will give you all you need - including
nice $? values. But: *** You have to run it! ***
systemd could also read from /proc itsself (basically that's what aa-
status does) - but that would mean to have AppArmor-specific code
(instead of a generic ExecStatus "hook") in systemd.
I don't need to explain you which way is better, right?
(And I hope Ludwig enjoys his popcorn (or leftover christmas cookies)
while I fight for a feature he'll also need for SuSEfirewall ;-)
- Apparmor parses its rules, if there is a ERROR
according to their
own concept of error, it aborts loading and returns failure exit
Yes, of course.
- If there is an error, that happens after parsing
according to its own rules, the transaction is rolled back, in an all
or nothing fashion and returns failure exit code, no half loading, no
You are still talking about "startup", and yes, at startup phase there
is error handling and proper exit codes.
Whatever else is a recipe for disaster... what I am
missing here ?
You are talking about startup ("rcapparmor start").
I am talking about checking the status _later_, _after startup_
it is just my idea or apparmor concept of starting is
brain dead ?
Someone could manually unload all AppArmor profiles (by manually running
apparmor_parser -R) and systemd would still tell you "apparmor: running"
because it was started by systemd. If something is brain dead, then it
must be systemd's assumption "I loaded it, so it must still be there".
The correct check is to run "aa-status", and this is why we need
ExecStatus (or, if everything else fails, a watchdog process).
And now please finally answer my question from yesterday:
> Now please tell me which way is smarter ;-)
Registrierter Linux-Nutzer #239431
Linux is like a wigwam:
no gates, no windows, but an apache inside.
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org