root access for end users

After a battle of years, "academic freedom" was invoked and very senior
management, in its infinite wisdom, has decided that our users (mostly
researchers) should have root access (or full sudo, which amounts to the
same thing) to their Linux workstations.

Does anybody have experience running a Unix/Linux network like this?

Remember full sudo means the ability to 'sudo su' and become any other
user, making permissions (even across NFS) useless. It also means the
ability to play with/pilfer/replace Kerberos keytabs, allowing one to
impersonate any box to which they have access. The support nightmare
cannot be used as an argument against this because users have convinced
management that "that's what support is for."

All I can do is control the servers and decide how services will be
presented and which hoops users should go through to be able to use
server resources.

The current environment is basically Kerberos authentication, NIS
authorization and NFS/CUPS services. Most of the clients are owned,
built, maintained and supported by my organization, but some users will
use their new found freedom to build/buy their own boxes.

The plan is to move away from NIS to LDAP and from NFS to AFS.

What other problems do people see? Any thoughts and suggestions will be
greatly appreciated.

TIA!

Yuri
--
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: root access for end users

Yuri Csapo a =E9crit :
> After a battle of years, "academic freedom" was invoked and very seni=
or=20
> management, in its infinite wisdom, has decided that our users (mostl=
y=20
> researchers) should have root access (or full sudo, which amounts to =
the=20
> same thing) to their Linux workstations.
>=20
> Does anybody have experience running a Unix/Linux network like this?
>=20
> Remember full sudo means the ability to 'sudo su' and become any othe=
r=20
> user, making permissions (even across NFS) useless. It also means the=
=20
> ability to play with/pilfer/replace Kerberos keytabs, allowing one to=
=20
> impersonate any box to which they have access. The support nightmare=20
> cannot be used as an argument against this because users have convinc=
ed=20
> management that "that's what support is for."
>=20
> All I can do is control the servers and decide how services will be=20
> presented and which hoops users should go through to be able to use=20
> server resources.
>=20
> The current environment is basically Kerberos authentication, NIS=20
> authorization and NFS/CUPS services. Most of the clients are owned,=20
> built, maintained and supported by my organization, but some users wi=
ll=20
> use their new found freedom to build/buy their own boxes.
>=20
> The plan is to move away from NIS to LDAP and from NFS to AFS.
>=20
> What other problems do people see? Any thoughts and suggestions will =
be=20
> greatly appreciated.
>=20
> TIA!
>=20
> Yuri

Really humbly, I'd just not recommend this full power to everybody if=20
there are NFS shares.

In my really smaller case i did not hesitate to modify extensively=20
default *nix groups (use me:staff instead of me:me, you:lab, her:lab
-> man usermod) and forced people to use the "newgrp" command for eac=
h=20
appropriate task (newgrp is really handy). I created groups for any kin=
d=20
of _role_ and added people into it (man groupadd, man usermod). Changed=
=20
also path group, and group write access on the pathes to the appropriat=
e=20
staffs.

This could not do all what you need, but you can fine tune sudo for the=
=20
rest. HTH
- ben
--
To unsubscribe from this list: send the line "unsubscribe linux-admin" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: root access for end users

Yuri Csapo wrote:

> After a battle of years, "academic freedom" was invoked and very senior
> management, in its infinite wisdom, has decided that our users (mostly
> researchers) should have root access (or full sudo, which amounts to the
> same thing) to their Linux workstations.
>
> Does anybody have experience running a Unix/Linux network like this?
>
> Remember full sudo means the ability to 'sudo su' and become any other
> user, making permissions (even across NFS) useless.

Don't use NFS with this access model. NFS is designed for the case
where the network administrators control all client systems and normal
users only have normal (non-root) accounts on those systems.

Use CIFS (Samba) instead. Each client connects to the server as a
specific user, and only has the access permitted to that user.

IOW, NFS has the client perform access checks, CIFS does it on the
server.

> It also means the
> ability to play with/pilfer/replace Kerberos keytabs, allowing one to
> impersonate any box to which they have access. The support nightmare
> cannot be used as an argument against this because users have convinced
> management that "that's what support is for."
>
> All I can do is control the servers and decide how services will be
> presented and which hoops users should go through to be able to use
> server resources.

Yep. That's hardly an uncommon environment, although it's not the
traditional "Unix network".

IMHO, it's not an unreasonable administrative decision, but it needs
to be borne in mind just how much changes, and how much work the
transition will require.

> The current environment is basically Kerberos authentication, NIS
> authorization and NFS/CUPS services. Most of the clients are owned,
> built, maintained and supported by my organization, but some users will
> use their new found freedom to build/buy their own boxes.
>
> The plan is to move away from NIS to LDAP and from NFS to AFS.
>
> What other problems do people see? Any thoughts and suggestions will be
> greatly appreciated.

If users have root access, they also have direct control over the
networking hardware, so you'll need to think about the underlying
network topology. One option is to replace any hubs with switches
(with port locking) and maintain physical security on the cables, but
it's probably easier to treat the bulk of the network as untrusted and
require users to log in to a VPN server.

--
Glynn Clements
--
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: root access for end users

Thank you everyone for your thoughtful input and suggestions. I thought
I'd summarize the replies here so everyone could benefit:

Suggested technical solutions: I will be considering them all in the
near future:

- ACLs
- Limited root kernels: rsbac and lids
- Samba as opposed to NFS
- Don't forget to secure the network infrastructure
- Treat the network as untrusted and mandate VPN

Other kinds of suggestions: some people (correctly I think) have
identified this as not a technical, but a political problem.

- Hire a lawyer and try to fight it out
- Stand up for your rights
- Try to communicate with users in their own terms

Other comments: I appreciate them all and agree with most :)

- This will be a nightmare
- Don't do it
- Quit
- It's your job. Get over it.


--
Yuri Csapo
Academic Computing & Networking
Colorado School of Mines
CT-256
Phone: (303) 273-3503
Fax: (303) 273-3475
Email: ycsapo@mines.edu

Please use the following link to open a service request:
http://helpdesk.mines.edu
===========================================
With a PC, I always felt limited
by the software available.
On Unix, I am limited only by my knowledge.
--Peter J. Schoenster
--
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html