[Freedombox-discuss] Dev: Granting Users Service Access?
Quoting Nick Daly (2013-11-06 15:38:50)
> Hi folks, did we ever arrive at a consensus on a general solution to
> the user-level password storage/accounts
I believe not.
> There are two basic approaches, both of which seem to have their
> disadvantages:
>
> 1. Keep user accounts separate for each service, let each service
> handle logins and user accounts. For example, if I hosted a XMPP
> and Wiki service on my box, users would have separate logins for
> each of those.
>
> This is bad because it duplicates logins and asks each service to
> handle logins on its own. If you're running five services on your
> box, chances are good that at least one of them is putting your
> login information at risk.
>
> This is good because it keeps your service level login separate
> from the system level login. Specific user accounts can't put the
> system at risk because they don't exist in the system.
What is (arguably) good is to keep user accounts and administration
accounts separate - which is a different issue from using same
_mechanism_ for both kinds of accounts.
> 2. Tie service logins into the system-level logins. For example, if I
> hosted an XMPP and Wiki service on my box, users would also have a
> system (shell) level login that each service looked to for
> authentication.
>
> This is bad because it hands malicious users a shell-level account.
> We could attempt to close that hole with the nologin shell, but it
> still feels dangerous. It also requires us to use services that
> can pass authentication off to other login services (see LDAP).
>
> This is good because it means users will have only a single
> password/authentication mechanism to guard. This increases system
> security by helping protect users from themselves. This also gives
> us a single point to modify and update authentication methods in
> the future.
What is bad is granting too big power to all user accounts.
> As far as I see it, those are our trade offs: put the user at risk (1)
> through foolish service configuration or put the system at risk (2) to
> malicious users. I'm leaning more toward option 2 because it
> *prevents individual users from engaging in bad password management
> practices,* but I'd like to hear if somebody has already thought this
> through.
>
> This came up because I *really* want to get password storage out of
> Plinth. It's fine that it's there now, but it should probably be
> removed by 1.0.
I suggest that we reuse system users/groups, both for your arguments
above and because that's the registry supported by Debian generally:
Bugs in our account or auth handling is then not obscure corner cases
for Debian at large, but should likely be treated as severe bugs in
commonly defined, understood and deployed Debian components.
I suggest that we propose two new groups to Debian (i.e. _not_ specific
to FreedomBox, by same reasoning as above):
* selfusers - members may remove their own account
* selfadmins - members may remove members of selfusers group
Existing Debian groups include "users", "adm", "sudoers" and "staff",
tempting to reuse but none fits our needs. Some of them are documented
in /usr/share/doc/base-passwd/users-and-groups.txt.gz and some in
/usr/share/doc/debian-policy/policy.txt.gz (when package debian-policy
is installed).
I suggest that we require this from FreedomBox services:
* administration services must serve only selfadmins
* administration services must operate only on selfusers
* user services must serve only selfusers
Above rules leave open if selfadmins are also selfusers - which arguably
weakens security but simplifies account handling (how else are selfusers
accounts administrated?).
Whether administration services use PAM, SASL or other mechanisms
(Petter have suggested use of system DBus) could be left open to each
implementation for now.
I like your suggestion to use nologin shell: Let's do that for *both*
selfusers and selfadmins accounts by default: In the context of
FreedomBox, using shell is a debugging aid only, so only ever relevant
in development, never in production.
Let's install avoid installing remote shell packages like sshd or
shellinabox: Need for shell access is an indication that FreedomBox is
not ready for production!
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20131106/58378295/attachment.sig>
Reply to: