On Tue, Mar 06, 2018 at 05:15:45PM +0100, Steve Grubb wrote:
> On Tue, 06 Mar 2018 14:34:58 +0000
> Stephen Gallagher <sgall...@redhat.com> wrote:
>
> > On Tue, Mar 6, 2018 at 9:24 AM Zbigniew Jędrzejewski-Szmek <
> > zbys...@in.waw.pl> wrote:
> >
> > > On Tue, Mar 06, 2018 at 01:03:30PM +0100, Steve Grubb wrote:
> > > > On Mon, 5 Mar 2018 23:11:12 +0000
> > > > Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> wrote:
> > > >
> > > > > - somewhat independently, systemd-sysusers has been beefed up
> > > > > so it is possible to use it to create system users before any
> > > > > files are installed on disk, but honouring admin overrides. In
> > > > > short, we now recommend the following invocation to create
> > > > > users for an rpm which contains files owned by those users:
> > > > >
> > > > > %sysusers_create_package %{name} %SOURCEN
> > > > >
> > > > > where %SOURCEN is the tmpfiles.d config file which will be
> > > > > installed by package. This expands to
> > > > >
> > > > > echo "u NAME - -" | systemd-sysusers
> > > > > --replace=/usr/lib/sysusers.d/NAME.conf - >/dev/null 2>&1 || :
> > > > >
> > > > > and the "u NAME - -" configuration is applied with a priority
> > > > > that /usr/lib/sysusers.d/NAME.conf normally has (so e.g.
> > > > > /etc/sysusers.d/NAME.conf will override this).
> > > > >
> > > > > [1]
> > > > > https://raw.githubusercontent.com/systemd/systemd/master/NEWS
> > > >
> > > > How does this interact with useradd and groupadd? Does this
> > > > replace them? And if so, does this send the required audit
> > > > events?
> > >
> > > It's a very simple tool to create system users and group
> > > in /etc/passwd. It just creates entries
> > > in /etc/{passwd,group,shadow}, and does not interact with audit in
> > > any way afaik.
> >
> > Is there some guideline that requires an audit log message to occur
> > whenever a user is added to a system?
>
> Yes. Absolutely. Even if that user is a system account.
>
> > We can't necessarily know on every end-user system when a user is
> > added by a central authority like FreeIPA, for example.
>
> That also has to be audited.
>
> > Even if we only limit it to dealing with /etc/passwd and friends, there are
> > still plenty of ways for this file to be modified that wouldn't cause
> > it to trigger an audit event unless we added a service to monitor
> > with inotify or similar.
>
> True. And we do include rules to catch these occurrences. But this not
> the preferred way because it does not give us the full information
> that is required. If we know that we are adding user accounts, we need
> to maintain the information for the whole lifecycle. If FreeIPA adds an
> account, it gets used and trips some audit events, then gets removed,
> we need the history of when it was added and when it was removed and
> by who.
I assume that there some standarized log message to be emitted in this
case? If this is documented somewhere, we could add that, although it'd
probably be easier if somebody who knows audit submitted a pull request.
The sysusers code is at
https://github.com/systemd/systemd/blob/master/src/sysusers/sysusers.c#L1205.
Zbyszek
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
