[SSSD] SSSD (another) wish-list

Stephen Gallagher sgallagh at redhat.com
Mon Nov 21 13:55:12 UTC 2011


On Mon, 2011-11-21 at 14:20 +0100, Ondrej Valousek wrote:
> On 11/21/2011 02:12 PM, Stephen Gallagher wrote:
> > The problem with having this updated on-the-fly is that it implies (by
> > necessity) that client applications have to have privilege to change
> > this at whim. That means that this information cannot be used as
> > authoritative (since the client could very possibly be lying about
> > this). I think it's probably better to rely on setting it at join time
> > with 'net ads' and then only allow it to be changed by an administrator
> > later.
> I do not understand. Not all applications have access, only those
> which have access to the system Kerberos database (krb5.keytab).
> Typically, only root (like sssd) applications have such an access and
> I can not imagine why would sssd lie about this....
> 
> Can you clarify?

Well, any root-level application can change this value. What this means
is that if root of the client was malicious (or simply obnoxious), they
could use the keytab to change this value at a whim, thus rendering the
option useless for searching, sorting, etc. This could potentially be
part of a complicated attack, as if a malicious user gained root access
on the machine, they could potentially delay a response (such as
patching a known vulnerability) by impacting the administrators'
abilities to see which machines were running an OS that was at risk.

Granted, that's a bit of a  contrived example, but as a rule I tend to
feel that data like this should be configured centrally, rather than
updated by clients. First rule of security: always assume your clients
are malicious.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20111121/3e797721/attachment.sig>


More information about the sssd-devel mailing list