How to deal with trojans?

[Daniel Gnoutcheff <daniel gnoutcheff name>]

While researching/brainstorming for my GSoC project, I've been thinking a lot
about related security issues, specifically the issue of trojan programs messing
with user settings data. It seems that, while this has long been a concern for
N-M development, it hasn't been addressed directly yet. I wanted to share a few
thoughts I have, with the hope that it will help organize our thinking in this
area.

As I see it, the bottom line is that we want to ensure that no changes are made
to network settings without the user's consent. That means we have two problems
to solve: 

(1) We want the N-M daemon to somehow be able to know that the user settings
    data it's getting really is what the user wants to send.

(2) We want the user settings data to be is stored in a way that trojans can't
    tamper with it.

We don't really do this right now. Any process that holds
org.freedesktop.NetworkManagerUserSettings is trusted by N-M, so any trojan can
kill any current N-M client and install themselves as the provider of settings
data. So problem (1) is not solved. And for problem (2), nm-applet stores much
of the settings data in gconf, unsecured.  Any user app, including a trojan, can
mess with network settings by messing with gconf keys. Indeed,
nm-connection-editor actually depends on this hole.

~~~

To solve problem (1), here are the options I can think of:

(A) Have N-M use PolicyKit to ask the user to provide their password whenever a
    program running in their name starts providing/editing settings data.

(B) Have a list of "known" NM-clients, i.e. those programs known to be
    legitimate providers of settings data. Have N-M only accept settings data
    from these trusted programs. N-M would have to actually inspect the N-M
    clients to ensure that they are what they seem and haven't been messed with
    by gdb or LD_PRELOAD or whatever.

(C) Similar to (B), but instead of having N-M verify the clients itself, have a
    special unix user account named, say "nm-clients", and have known NM-clients
    installed setuid "nm-clients". That is, NM-clients will be running with real
    UID == the user represented by the client and effective UID == "nm-clients",
    and we know that a program is a legitimate NM client if and only if it has
    effective UID "nm-clients". We then setup DBus policy restrict the relevant
    N-M daemon interfaces to user "nm-clients".

(D) Also similar to (B), but use SELinux to do the enforcement. We have a
    security context for known NM-clients, and we use the SELinux support in
    DBus to ensure that only apps in that context can supply settings data.

Option (A) is probably too annoying to be worthwhile. Option (B) is better, but
it would be difficult to implement and would require a whole mess of
verification logic that's hard to get right. Option (C) is better, but getting
NM-clients to work when running setuid probably would be annoying, and having
each client run in the same unix user account probably would increase the risk
of data leaks between users.

Option (D) is my favorite. I believe that SELinux is powerful enough that it
could do the job with very little modification to the N-M daemon and clients.
Simplicity of implementation is a big win for security. However, on systems
without SELinux, we would not be any more secure than we are now. But I think
this is a reasonable trade-off. If a system doesn't have something like SELinux
and a user has a trojan running in their account, they're probably screwed
anyway. So getting N-M to resist trojans wouldn't really buy us much there. It's
not worth the pain, I think.

~~~

As for the trojan-resistant settings storage problem, we might:

(A) Move all settings storage into the N-M daemon. Then, everything is under
    root's protection. (This mimics the strategy Unix has long used to protect
    user passwords from tampering.)

(B) Store user settings in the user's homedir, but have the files owned by a
    special unix user, e.g. our "nm-clients" user from before. If we make sure
    that we only accept config files owned by "nm-clients", this should ensure
    that only known NM-clients can edit config data.

(C) Store user settings in the user's homedir and use SELinux to safeguard it.

Option (A) is interesting because it would solve the fast-user-switching problem
and the user-settings-editing-over-DBus problem, which are the two problems I
promised to work on for GSoC. (More on this in another e-mail.) However, this
increases the amount of stuff being done in UID 0, which is a bad thing esp. if
you keep the principle of least privilege in mind. So I think we want to avoid
this.

Fortunately, options (B) and (C) seen workable. (C) is probably better, since
it's less likely to lead to data leaks between users.

~~~

Well, thanks for reading that! Comments, corrections, better ideas?

Have a great one,
Daniel