On Tue, 06 Mar 2018 14:34:58 +0000
Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote:
> On Tue, Mar 6, 2018 at 9:24 AM Zbigniew Jędrzejewski-Szmek <
> zbyszek@xxxxxxxxx> 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 <zbyszek@xxxxxxxxx> 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.
> So, I don't see this being any worse than the current state of the
> art. Realistically, such an audit event is useless and noisy;
Not really, it gives us information about account creation or removal
and who did it. This may be normal or an anomaly.
> whether a user is *available* is not interesting in comparison to when that
> user logs in.
That is also interesting as are a lot of things. But if we are creating
accounts then we need the whole lifecycle recorded.
-Steve
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
