On Mon, Feb 18, 2013 at 06:07:08PM +0100, Michal Schmidt wrote: > Hello Fedora kernel maintainers, > > please consider setting CONFIG_AUDIT_LOGINUID_IMMUTABLE=y for F19. > > It brings a security benefit and should be safe to turn on since > we're using systemd to start services. Refresh my memory please. Are we using systemd to start 100% of the services provided in Fedora? I seem to recall there are still a number of packages not using/providing systemd unit files. Would enabling this cause them to get weird EPERM errors? Is there a simple thing to check for aside from EPERM if issues from this do pop up?

On 02/18/2013 01:32 PM, Eric Paris wrote: > On Mon, 2013-02-18 at 13:15 -0500, Josh Boyer wrote: >> On Mon, Feb 18, 2013 at 06:07:08PM +0100, Michal Schmidt wrote: >>> Hello Fedora kernel maintainers, >>> >>> please consider setting CONFIG_AUDIT_LOGINUID_IMMUTABLE=y for F19. >>> >>> It brings a security benefit and should be safe to turn on since >>> we're using systemd to start services. >> >> Refresh my memory please. Are we using systemd to start 100% of the >> services provided in Fedora? I seem to recall there are still a number >> of packages not using/providing systemd unit files. Would enabling this >> cause them to get weird EPERM errors? >> >> Is there a simple thing to check for aside from EPERM if issues from >> this do pop up? > > Daemons with a config requiring pam_lognuid.so will be unable to work if > they are launched by a logged in admin as opposed to systemd. Obvious > work around is to change the pam config. > > Login daemons launched by sysinit at boot will work. > Login daemons launched by systemd will work. > > Login daemons launched by sysint from a logged in admin will fail. Assuming that systemd launching an "old" sysvinit script will work, this should be safe. I do not believe Fedora contains any other viable init mechanisms anymore (upstart is gone, sysvinit is a husk).

On Mon, Feb 18, 2013 at 01:42:09PM -0500, Eric Paris wrote: > On Mon, 2013-02-18 at 13:38 -0500, Tom Callaway wrote: > > On 02/18/2013 01:32 PM, Eric Paris wrote: > > > On Mon, 2013-02-18 at 13:15 -0500, Josh Boyer wrote: > > >> On Mon, Feb 18, 2013 at 06:07:08PM +0100, Michal Schmidt wrote: > > >>> Hello Fedora kernel maintainers, > > >>> > > >>> please consider setting CONFIG_AUDIT_LOGINUID_IMMUTABLE=y for F19. > > >>> > > >>> It brings a security benefit and should be safe to turn on since > > >>> we're using systemd to start services. > > >> > > >> Refresh my memory please. Are we using systemd to start 100% of the > > >> services provided in Fedora? I seem to recall there are still a number > > >> of packages not using/providing systemd unit files. Would enabling this > > >> cause them to get weird EPERM errors? > > >> > > >> Is there a simple thing to check for aside from EPERM if issues from > > >> this do pop up? > > > > > > Daemons with a config requiring pam_lognuid.so will be unable to work if > > > they are launched by a logged in admin as opposed to systemd. Obvious > > > work around is to change the pam config. > > > > > > Login daemons launched by sysinit at boot will work. > > > Login daemons launched by systemd will work. > > > > > > Login daemons launched by sysint from a logged in admin will fail. > > > > Assuming that systemd launching an "old" sysvinit script will work, this > > should be safe. I do not believe Fedora contains any other viable init > > mechanisms anymore (upstart is gone, sysvinit is a husk). > > What breaks is admin running > > /usr/sbin/sshd -D > > or > > /usr/sbin/crond -n > > unless they redo their stock pam config... And there's no way we can fix the stock pam config so they don't have to do that? A more pointed question is, when people complain this stops working and the R word starts getting thrown around, can I point them at you and Michal?

On Mon, Feb 18, 2013 at 02:36:04PM -0500, Eric Paris wrote: > On Mon, 2013-02-18 at 14:28 -0500, Josh Boyer wrote: >> On Mon, Feb 18, 2013 at 01:42:09PM -0500, Eric Paris wrote: >>> What breaks is admin running >>> >>> /usr/sbin/sshd -D >>> >>> or >>> >>> /usr/sbin/crond -n >>> >>> unless they redo their stock pam config... >> >> And there's no way we can fix the stock pam config so they don't have to >> do that? Do you happen to have an example of how to modify the pam config to let people still do this? If so, could you send it here?