-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
so, sometimes we've had problems with the Toolserver that required an admin, but an admin wasn't always around. some of these problems are complicated, but others are simple, and can be fixed by e.g. killing a process, or rebooting a server. to reduce the chance that something like this occurs when no admins are around, i have come up with an idea for a new class of user, which i've termed "Toolserver custodians".
custodians would have a limited set of admin privileges, which i imagine might include:
* rebooting login/web servers * killing user processes * viewing and killing user queries on MySQL servers
because none of these rights allow access to privileged information, we can assign them more freely than root access, and without requiring consent from the Wikimedia Foundation.
does this seem like something that would be helpful? and, if we introduced it, would anyone be interested in such privileges? (we would probably require a good knowledge of Unix and at least some experience with system administration.)
- river.
does this seem like something that would be helpful? and, if we introduced it, would anyone be interested in such privileges? (we would probably require a good knowledge of Unix and at least some experience with system administration.)
I am interested. I have plenty of experience with Unix-type systems, and am a current Linux system administrator for a small, not-for-profit organisation.
Out of interest, how would these limited rights be implemented?
Fahad
On 27. aug. 2009, at 09.44, Fahad Sadah fahadsadah@googlemail.com wrote:
does this seem like something that would be helpful? and, if we introduced it, would anyone be interested in such privileges? (we would probably require a good knowledge of Unix and at least some experience with system administration.)
I am interested. I have plenty of experience with Unix-type systems, and am a current Linux system administrator for a small, not-for-profit organisation.
I am interested too. I have experience in administrating a server in the same non-profit organsation as Fahad, but another server.
Out of interest, how would these limited rights be implemented?
I would guess that the easiest way would be some kind of daemon running as root.
Fahad
Henrik Hodne
On Thu, Aug 27, 2009 at 10:06 AM, Henrik Hodnedvyjones@cluenet.org wrote:
Out of interest, how would these limited rights be implemented?
I would guess that the easiest way would be some kind of daemon running as root.
Daemon? Why not just sudo?
--leafnode
On 27. aug. 2009, at 10.14, Leszek Krupinski leafnode@gmail.com wrote:
On Thu, Aug 27, 2009 at 10:06 AM, Henrik Hodnedvyjones@cluenet.org wrote:
Out of interest, how would these limited rights be implemented?
I would guess that the easiest way would be some kind of daemon running as root.
Daemon? Why not just sudo?
Doh! I keep forgetting you can limit privileges with sudo.
Henrik
2009/8/27 Henrik Hodne dvyjones@cluenet.org:
On 27. aug. 2009, at 10.14, Leszek Krupinski leafnode@gmail.com wrote:
On Thu, Aug 27, 2009 at 10:06 AM, Henrik Hodnedvyjones@cluenet.org wrote:
Out of interest, how would these limited rights be implemented?
I would guess that the easiest way would be some kind of daemon running as root.
Daemon? Why not just sudo?
Doh! I keep forgetting you can limit privileges with sudo.
Henrik
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Bear in mind that most programs can be exploited as root, to gain full root. Might I remind you of what happened with mount (for those of you who don't know, a bunch of people from the not-for-profit organisation me and Henrik volunteer for, abused access to mount, to take a whole server, by making their own filesystems with setuid binaries inside, and mounting them)
Fahad
On Thu, Aug 27, 2009 at 4:14 AM, Leszek Krupinskileafnode@gmail.com wrote:
Daemon? Why not just sudo?
Or Solaris roles or whatever they're called, on the Solaris machines. (Whatever it is pfexec does.) MySQL wouldn't even need that; just assign the account the right to view process lists and kill processes.
On Thu, Aug 27, 2009 at 5:05 AM, Fahad Sadahfahadsadah@googlemail.com wrote:
Bear in mind that most programs can be exploited as root, to gain full root. Might I remind you of what happened with mount (for those of you who don't know, a bunch of people from the not-for-profit organisation me and Henrik volunteer for, abused access to mount, to take a whole server, by making their own filesystems with setuid binaries inside, and mounting them)
Not "most programs", only a minority. Obviously if you can run mount as root with arbitrary parameters, you can mount arbitrary filesystems with, for instance, a setuid root-owned binary on it that does whatever you want. Giving people sudo access to chmod, chown, modprobe, a shell or interpreter or editor, something that's not usually a shell or interpreter or editor but actually can be used as one (like some variants of less), etc., would also obviously give them full access if they wanted.
But you're not going to get root access using shutdown or kill or /etc/init.d/apache. It does pay to think about it carefully first, but it's hardly inevitable that limited admins will be able to get full root if you're careful what commands you give them. (I'd think it would be safer to write a wrapper script for kill that made sure you weren't trying to kill a root-owned process, to be on the safe side.)
On Thu, Aug 27, 2009 at 8:09 AM, Bryan Tong Minhbryan.tongminh@gmail.com wrote:
Well of course they can, and care should be taken which programs can be run, but custodians should be very trusted and anybody whom we don't know if they will exploit a program to gain root access is automatically disqualified.
If there were some way we knew about that some users could gain root access (and thereby access to private data), those users would have to be approved by Wikimedia, which defeats the point.
On Thu, August 27, 2009 4:23 pm, Aryeh Gregor wrote:
But you're not going to get root access using shutdown or kill or /etc/init.d/apache.
I would not be too certain about that. For example, buffer overflows are generally only a security problem when they happen in suid-root programs - this is why programs designed to be suid root have thorough checks on such problems. Software designed to be used by root does not always have the same thoroughness of checks - and running such software via sudo could expose these errors as security problems.
-Merlijn
On Thu, Aug 27, 2009 at 11:54 AM, Merlijn van Deenvalhallasw@arctus.nl wrote:
I would not be too certain about that. For example, buffer overflows are generally only a security problem when they happen in suid-root programs - this is why programs designed to be suid root have thorough checks on such problems. Software designed to be used by root does not always have the same thoroughness of checks - and running such software via sudo could expose these errors as security problems.
Any widely-used software with a known buffer overflow gets fixed. This is just as true for shutdown as for ping. You're far *more* likely to find a serious vulnerability in the kernel or services that run as root, just because of their vastly greater LOC. A user who was dedicated enough to try finding a buffer overflow in kill (which is only 16K compiled on nightshade, BTW, and I doubt it's often been changed) could save himself some effort by just waiting for a kernel privilege escalation vulnerability announcement and pulling a zero-day exploit.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Fahad Sadah:
Out of interest, how would these limited rights be implemented?
using a set of small, secure setuid programs i would write for the purpose.
we can't use sudo because there's no way to say "allow this user to run kill as root as long as he's only killing a user process". furthermore we would want to make sure the user sends an explanation to the user whose process was killed.
we can't use MySQL permissions because there's no way to let a user view all threads except the replication thread (which could expose private data).
we can't use Solaris RBAC (pfexec) for the same reason as sudo. however, RBAC _does_ allow fine-grained privileges (unlike sudo), and we could use RBAC to implement authorisation to use the setuid utilities. however, i won't do it this way because then it wouldn't work on Linux, which doesn't support RBAC.
- river.
On Thu, Aug 27, 2009 at 8:12 AM, River Tarnellriver@loreley.flyingparchment.org.uk wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
so, sometimes we've had problems with the Toolserver that required an admin, but an admin wasn't always around. some of these problems are complicated, but others are simple, and can be fixed by e.g. killing a process, or rebooting a server.
I believe most of the recent cases that required an admin, was real admin work, things like broken replication, broken servers, etc.
- rebooting login/web servers
- killing user processes
- viewing and killing user queries on MySQL servers
Urgent problems with killing user processes and killing user queries are rare. Nevertheless although they don't happen often, they do happen and if somebody else than an admin is able to fix it, the reliability of the toolserver would be increased.
does this seem like something that would be helpful? and, if we introduced it, would anyone be interested in such privileges? (we would probably require a good knowledge of Unix and at least some experience with system administration.)
I don't think there would be large benefit gained from the proposal, but on the other side it doesn't hurt to have custodians, as long as they are trusted.
In any case I would be willing to volunteer. I have limited experience with linux system administration and none with solaris, but I do know where to find man pages and I am quite familiar with the various parts of the toolserver cluster.
On Thu, Aug 27, 2009 at 11:05 AM, Fahad Sadahfahadsadah@googlemail.com wrote:
Bear in mind that most programs can be exploited as root, to gain full root.
Well of course they can, and care should be taken which programs can be run, but custodians should be very trusted and anybody whom we don't know if they will exploit a program to gain root access is automatically disqualified.
Bryan
toolserver-l@lists.wikimedia.org