Hello, 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 Rodríguez:
On 28/12/11 16:01, Per Jessen wrote:
Cristian Rodríguez wrote: Try the 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...)
Auditing (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) ;-)
That method 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 ?
See below.
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 security !!
It does provide a way to check the status - but not in the way systemd likes;-) There is nothing like a process or a pid file (both wouldn't make any sense). 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 code.
Yes, of course.
- If there is an error, that happens after parsing (loading), again 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 inconsistent status.
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_ ("rcapparmor status").
it is just my idea or apparmor concept of starting is totally 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 ;-)
Regards, Christian Boltz -- Registrierter Linux-Nutzer #239431 Linux is like a wigwam: no gates, no windows, but an apache inside. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org