Suggestions (~wishlist)

[Teddy Hogeborn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lee Winter <lee.j.i.winter at gmail.com> writes:

> Mandos Suggestions
> 
> 1.  Alternative plugin to allow operator to provide host-specific
>     boot password on removable media such as floppy, CD, or USB.
>     The idea is that a user could construct a "master boot key"
>     containing all of his boot keys and just plug it in during boot

As I understand it, this already exists outside of Mandos; See the
documentation about 'The "passdev" keyscript' in
"/usr/share/doc/cryptsetup/README.initramfs.gz".

I suppose we could write a Mandos plugin which in turn runs "passdev",
but I don't really see much point to it?  If this is what someone
wanted, wouldn't they just use "passdev" *instead* of Mandos?

> 2.  The only feature I need to overcome the limitations of the
>     heartbeat poll is a way to disable the mandos server.  if that
>     feature is available then the clients can be thoroughly
>     secured.  But that should be part of the UI for the server.

I agree - this is already an item in the TODO file.

>     Below is that I suggest that UI should support:
> 
> A. Notification -- when a client requests a key
>         primary: execute something external
>                 typically a user-defined program or script
>                 should provide some details such as client's host
>                 name as parameter

Yes, this was also what I thought at first, but then I realized that
providing notifications via D-Bus was cleaner and more flexible.  When
you think about it, any and all events in a server is a possible place
to add such "execute some program" hooks, and this either becomes
unwieldly or one would have to make a large number of arbitrary
judgment calls on what events would be interesting or useful enough to
warrant a hook.

So, I have no plans to implement this, since any program wanting to do
this will be able to just hook itself up to the D-Bus system bus and
wait for the Mandos server to send an appropriate signal (with useful
information attached).

>         secondary: 
>                 write status to a file, such as a log

The server already sends log messages to syslog(3); it should be
possible to configure the syslog daemon to send the log anywhere.  I
think this is the proper division of abstractions in this case.  Also,
for any event warranting a log message, a D-Bus signal will be sent,
too.

>                 change the contents of a status-oriented web page
>                 (external poll)
>                 send an email
>                         provide details in body of message

As above, this can be implemented using programs listening for the
server's D-Bus events.  I do not plan to write such programs myself at
this time - I'm looking at other features (such as the D-Bus interface
itself) at the moment.  However, contributions are always very
welcome!

> B.  Operating Modes (for the server and for each client)
>         1. Just do it -- as current operation is defined
>         2. Wait for permission*, impatiently optimistic (affirmative
>            timeout = no operator action -> give out key)

Good idea; I've added it to the TODO file.

>         3. Wait for permission*, patiently (no timeout = wait
>            forever)

Hmm, I had thought about this, but I see now that it's not in the TODO
file; I've now added it.  Thanks!

>         4. Ask permission*, impatiently pessimist (negative timeout
>            = no operator action -> disable client)

I don't see the point of this - couldn't the client just be disabled,
and the operator could then enable it when desired?  But then the
client wouldn't ask that server again until it re-announces itself, so
should the server do that?  I don't know what the best way to
implement this is, so I'll decide that later, but I agree that the
basic functionality should be there.

>         5. Don't do it -- disabled

Yes, already in the TODO file.

>         A client's effective mode is the maximum of the client's
>         assigned mode and the server's (global) mode.

Wait a minute.  My comments above are about the *server* modes.  What
use would any of the modes above be, as applied to the *client*?
Let's enumerate:

Mode 1: N/A

Mode 2: What would this mean?  That the client just sleeps for a time
        before asking the network server?  This could be implemented
        easily enough, but what would be the use?

Mode 3: I guess this would mean that the client waits for confirmation
        on its console before asking the network?  This would be very
        tricky to implement; the console (or equivalent) is taken by
        another plugin asking for the password.  I suppose one could
        disable those plugins or add a feature to them to signal the
        "mandos-client" plugin.  But I see absolutely no use for it -
        if a someone is right there on the console, couldn't they just
        as well type in the password?

Mode 4: Isn't this the effective mode of *not* having Mandos?  (This
        can be achieved by passing "mandos=off" on the kernel command
        line, by the way.)

> C.  Control panel
>         Access
>                 accept only secured connections
>                 option to limit connections to only designated FQDN
>                 or IP address.

My current thought is to punt on this and provide a D-Bus interface on
the server and some command-line tools which uses it (D-Bus is
accessible on the local host only, and the Mandos server's D-Bus
interface will require root privileges to access).  If someone wants
to write a web interface, they'll have to decide on a security model
themselves - it feels to me like what people would want is too diverse
for me to just arbitrarily pick something.  I'm thinking that someone
will eventually write a web interface and contribute it, and we'll
then be happy to include it.

>         Actions
>                 allow changes to operating modes (described above)
>                 per client and/or globally

Yes, I agree.

>                 supply or deny permission for pending client's
>                 requests for keys

Yes.

> D.  Stability
>         Rebooting the client should not affect its assigned
>         operating mode

Where in the world would the client save this information?  There is
nowhere to write anything - the client runs in the initial RAM disk
environment; everything is ephemeral.

>         Rebooting the server should not change anything about how
>         clients are handled.

Yes, of course - this was always the intention of the idea of the
server having a persistent state.  Hmm, I see that this is not in the
TODO file; I've now added it.

/Teddy Hogeborn

- -- 
The Mandos Project
http://www.fukt.bsnet.se/mandos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFKsu06OWBmT5XqI90RAqaLAJ0R4U8JC9ceCipNqLgJmdC0KD8yZQCgi+Qt
qZhrdlG+/AOWuvQotmtVSgM=
=b2aj
-----END PGP SIGNATURE-----