Created attachment 433779 [details] Native systemd file for auditd Description of problem: The attached file is a native systemd file for upcoming F14 Feature [1] Please read [2] on how to installing systemd Service files. 1.http://fedoraproject.org/wiki/Features/systemd 2.https://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/Daemon#Installing_Systemd_Service_Files If you have any question dont hesitate to ask them on this bug report. Thank you. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Few questions. 1) How is resume, rotate, and reload supported in systemd? 2) Auditd is a security sensitive component and quite a few services should wait until its running before they start: sshd, login, crond, gdm, kdm, xdm, vsftpd, raccoon, dbus, amtu, cups, and nscd. There are probably more. 3) Does systemd meet our security requirements? a) We must record system startup/shutdown/runlevel changes to the audit system. b) We must record the startup of any service - even if it fails to the audit system. c) We need "service foo start" to tell init to do the startup so that anything in the admin's session does not get into the service's environment. There are things in the processes' task structure in the kernel that get leaked. Thanks.
Any comments on the above security requirements?
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Regarding 1) -- systemd's systemctl tool only understand the verbs necessary for maintaing the service at runtime. Additional verbs available in the various init scripts cannot be used with systemctl. But that should be fine. For now it should be fine if the user would simply call /etc/init.d/auditd for this as he always did. (Note that I am not a particular fan of these additional verbs which just send a signal. The verbs should be synchronous and return only after the operation completed, but sending a signal is asyncrhonous and returns immediately). In the long run I think it would make sense to provide a dedicated client utility that does these operations synchronously and without involving the init script. Regarding 2) the services you listed, why exactly to they need auditd? Do they communicate with auditd? how does that communication work? is it AF_UNIX based? or AF_NETLINK based? Usually if it is AF_UNIX based my recommendation would be to make auditd socket activatable which would allow us to start it in parallel with the clients wanting to talk to it, without further synchronization. If that is not possible we can add explicit synchronization however, by adding "After=auditd.service" to the various service files of the various unit files, or something similar to the LSB headers (where it should already be available anyway?) Regarding 3): well, we carry a number of selinux patches already, so there has been work in this direction. regarding a) it would be easy to add this i presume. I see no code for this in upstart, how is this done right now? We have no notion of runlevels anymore. How free-form is this? if you point me to some example code I am happy to prep a patch for this. regarding b) we record this anyway, so forwarding this to auditd should be easy (and much nicer then with sysv). if you point me to some example code, i'd be happy to hack this up, too. How does the communication work here? i.e. we probably need to avoid deadlocks here that we try to notify audit that audit has started and so on. regarding c) systemd guarantees a completely clean execution environment for all the services it starts. The processes are forked off PID 1 and hence do not inherit anything from the users shell where he might run "systemctl start apache.service" from. Does that answer your questions?
Moving systemd service RFEs to rawhide. At this point, it is not appropriate in the Fedora 15 cycle to add these. Furthermore, at this point, we are still finalizing the packaging guidelines to handle SysV -> systemd upgrades. We therefore request: - wait until there are packaging guidelines (this will be announced on the devel list). This ensures that upgrades will work smoothly and we/you won't have to do multiple sets of changes. - work on these sorts of changes for Fedora 16 where necessary, not Fedora 15, as we're trying to fix things for release. - do *not* change a service from SysV to systemd in an existing release (such as Fedora 15), as this is the sort of behavior change that goes against our update policy, documented as https://fedoraproject.org/wiki/Updates_Policy
*** Bug 714447 has been marked as a duplicate of this bug. ***
What's the current status on this and note as per packaging guidelines the old sysv init script would be packed in a separate subpackage if the intention is to continue to maintain and support. 1.https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd
Created attachment 509720 [details] Spec file which introduce systemd unit file and drop SysV support for auditd.service Spec file which introduce systemd unit file and drop SysV support for auditd.service I threw in here a spec file which introduce systemd unit file and drop SysV support for the submitted auditd.service encase there continues to be no move on this report so we dont end up blocking the alpha release you can then update the service file with what ever the final outcome will be went. Note that this spec file will remove the old sysv init script if you have any intention of continuing supporting the legacy sysv init script you will need to update this spec and package the legacy sysv script separately in a sub package as stated by the packaging guidelines.
The status on this bug is that I need to get support for systemd upstream. After that is worked out, I'll build for rawhide. But I was also curious if everything that uses the audit system has their After= set to the audit system? That would be things like: sshd, gdm, kdm, xdm, crond, vsftpd, dbus, and login. There may be a couple others like rshd, but its so rarely used I don't know if its patched offhand.
Nope not to my knowledge hence it's so important that we push out an services as soon as possible so we can catch those After= and Before= is the submitted service file not good enough to be pushed to rawhide or do we explicitly need to wait after systemd gets patched ?
Oh yeah I should mention it's probably best that you add all the service that need to be mounted after auditd.service to a Before=<list of service file ) line in auditd.service as opposed to them add it to their native systemd service file as in the form of After=auditd.service
two+ weeks has passed any updates? Are you and Lennart working together solving the technical issues regarding this ?
I am planning to release a new audit package in the next few weeks. That one will have the systemd based init script.
Hum how long is next few weeks as in will it be done before the "Alpha Change Deadline" ( 2011-08-02) Preferable a week before ( 26 July ) to not to disturb the regular QA process to much?
Will this be ready for thursday?
I will see what I can do. I have much more important things to do right now. I have decided that upstream will not support systemd at this point. There are too many issues that are unclear to be able to support both traditional and this new init until more time passes and a consensus is developed. So, for now doing it all from the spec file is the way forward.
Hum could you clarify? Are you talking about from packaging perspective or systemd? ( or both ) Anway it would be good to get the problem outlined here so we can see what can be done to solve it
From a packaging perspective. The initscript for sysvinit will have to be manually deleted and the new one installed in the spec file. I also do not plan to make any code changes one way or another based on what init system is being used.
Hum I see I have not posted the actual approved guidelines which you might be missing along with the script snippet samples https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd https://fedoraproject.org/wiki/Packaging:Tmpfiles.d
Hmm...doesn't really change my opinion. I think its a big mistake to put config information in /lib. But this bz is not the place for that discussion. If you are a proven packager, you have my permission to make the changes to the audit package specfile to install the unit file at the correct place if you wanted.
Created attachment 515378 [details] Spec file patch for auditd
(In reply to comment #20) > Hmm...doesn't really change my opinion. I think its a big mistake to put config > information in /lib. But this bz is not the place for that discussion. If you > are a proven packager, you have my permission to make the changes to the audit > package specfile to install the unit file at the correct place if you wanted. Provided a spec file patch for proven packager to review and commit if error free..
Thank you for the patch, I applied it and pushed it through the build system: http://koji.fedoraproject.org/koji/taskinfo?taskID=3232731 There was a couple minor adjustments to get it to build but seems ok. I'm sure if there are problems, I'll hear about. :) Please try it out and let me know if we have to rebuild it.
audit-2.1.3-2.fc16 (which is newer than 2.1.2-2, where Steve committed the change to add systemd support) is in f16 stable. Closing this bug out.