FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 10-21-2010, 04:49 AM
Christian PERRIER
 
Default disabled root account / distinct group for users with administrative privileges

Quoting Russ Allbery (rra@debian.org):

> > How about the "root" group?
>
> Any already-existing group is going to have the problem that some sites
> will already be using it for something else. We put all sysadmins in


Isn't that the same for any kind of clever group name we'll find?
Unless we choose something really weird, there will always be someone
already using that name....

Maybe sudo is not that bad, after all..:-)


another idea: "sudoroot"?


And for ${deity}'s sake, people (not Russ, who I'm answering to)
should stop talking about 'bikeshedding'. Yes, that makes one look
smart. French has a less smart definition for activities where one
discuss things before taking decision and that involves having
(preferrably safe) sex with flies. It has about the same condescendent
implication: the discussion is useless.

This discussion is not.

We will have to live with whatever group name we choose
now for *years*, so better carefully choose it now. Sorry for bikes
and flies....
 
Old 10-21-2010, 08:52 AM
Ben Finney
 
Default disabled root account / distinct group for users with administrative privileges

Christian PERRIER <bubulle@debian.org> writes:

> And for ${deity}'s sake, people […] should stop talking about
> 'bikeshedding' [which has the condescending] implication: the
> discussion is useless.
>
> This discussion is not.
>
> We will have to live with whatever group name we choose now for
> *years*, so better carefully choose it now.

Bravo! Just because some discussions about details are futile, many
discussions about details are necessary to avoid future problems. The
mis-application of the “bikeshed” label is toxic to fixing small
problems before they become bigger.

Thanks, Christian.

--
“I find the whole business of religion profoundly interesting. |
` But it does mystify me that otherwise intelligent people take |
_o__) it seriously.” —Douglas Adams |
Ben Finney
 
Old 10-21-2010, 09:03 AM
Michael Banck
 
Default disabled root account / distinct group for users with administrative privileges

Hi,

On Tue, Oct 19, 2010 at 12:38:41AM +0200, Michael Biebl wrote:
> So, I'm wondering if we shouldn't pick a more neutral name without a previous
> history in Debian.
> One suggestion is to use group "admin". Ubuntu has been using that group for
> exactly the purpose what we are going for and I think it is a pretty
> adequate name.
>
> One concern that was already mentioned is, that the existing group adm and admin
> are too similar and prone to mistyping.

Now that we ruled out most of the alternatives (maybe except "staff"
yet?), I re-read this and believe this is not such a great argument.

"admin" is used by Ubuntu already, which I think is a fairly strong
argument in favor of it.

And really, who needs typing those groups? Only sysadmins I guess, and
I believe we trust them to either keep "adm" and "admin" apart and/or
fix up their error afterwards. There is more than this (non-)issue to
shoot yourself in the foot as root on the commandline, if you are
care- or clueless.

How will regular users get in contact with "admin" (or even "adm"?) and
how would this be confusing and/or a possibility for mistyping? I think
this is the question we need to address.


Cheers,

Michael


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20101021090336.GE32672@nighthawk.chemicalconnectio n.dyndns.org">http://lists.debian.org/20101021090336.GE32672@nighthawk.chemicalconnectio n.dyndns.org
 
Old 10-21-2010, 09:37 AM
Russ Allbery
 
Default disabled root account / distinct group for users with administrative privileges

Christian PERRIER <bubulle@debian.org> writes:
> Quoting Russ Allbery (rra@debian.org):

>> Any already-existing group is going to have the problem that some sites
>> will already be using it for something else. We put all sysadmins in

> Isn't that the same for any kind of clever group name we'll find?
> Unless we choose something really weird, there will always be someone
> already using that name....

> Maybe sudo is not that bad, after all..:-)

> another idea: "sudoroot"?

Yeah, that's the argument for using something relatively obscure, although
I agree with the point that using Debian-* for this probably isn't wise
since those are really for local system groups that the sysadmin shouldn't
have to think about and which are artifacts of specific packages.

Really, ideally, this is something that would be standardized across
distributions.

I like sudoroot, personally, but I think sudo is probably okay.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 871v7j7upk.fsf@windlord.stanford.edu">http://lists.debian.org/871v7j7upk.fsf@windlord.stanford.edu
 
Old 10-21-2010, 03:48 PM
Philip Hands
 
Default disabled root account / distinct group for users with administrative privileges

On Thu, 21 Oct 2010 06:49:00 +0200, Christian PERRIER <bubulle@debian.org> wrote:
> Quoting Russ Allbery (rra@debian.org):
>
...
> Maybe sudo is not that bad, after all..:-)

If we decide to reject 'admin', I think we should use sudo. I find the
argument that admin is confusing given the presence of adm fairly
convincing -- It's all too easy to say something like "could you add
fred to the adm group" over the phone and pronounce 'adm' as 'admin'.

Sadly, we are not the first to make this decision though, and having
admin on Ubuntu and sudo on Debian would be a pain for people that have
mixed sites, or even for admins that just have access to some of each.

What is the likelihood that Ubuntu might switch to using sudo for this if
we settled on that? (my guess is that they'd stick with admin)

Given that we've had the sudo group for a while, and we're tightening up
the passwordless aspect of that anyway, it is a perfect fit.

On balance, I favour sudo for this, but wouldn't be too unhappy with
admin -- the most important thing is that we have such a group defined.

Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] http://www.hands.com/
|-| HANDS.COM Ltd. http://www.uk.debian.org/
|(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND
 
Old 10-21-2010, 03:59 PM
"Giacomo A. Catenazzi"
 
Default disabled root account / distinct group for users with administrative privileges

On 20.10.10 13:28, Simon McVittie wrote:


Quoting from base-passwd again:

Allows users to add local modifications to the system (/usr/local, /home)
without needing root privileges. Compare with group 'adm', which is more
related to monitoring/security.

Note that the ability to modify /usr/local is effectively equivalent to
root access (since /usr/local is intentionally on search paths ahead of /
usr), and so you should only add trusted users to this group. Be careful in
environments using NFS since acquiring another non-root user's privileges
is often easier in such environments.

... so in practice, staff is root-equivalent, but in principle it's not meant
to be. (Yay.)


It depends on the definition of "equivalent".

Anyway "staff" is a protection against user (aka admin)* errors*, not
against *malicious* admins.


And this is still an important feature (IMHO), thus with different
objectives as the original proposal.


ciao
cate


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4CC0637B.7070404@debian.org">http://lists.debian.org/4CC0637B.7070404@debian.org
 
Old 10-21-2010, 10:56 PM
Carsten Hey
 
Default disabled root account / distinct group for users with administrative privileges

* Russ Allbery [2010-10-21 02:37 -0700]:
> I like sudoroot, personally, but I think sudo is probably okay.

A group named sudo or sudoroot is somehow linked to sudo as tool used to
gain administrative privileges. No one knows if in future an other tool
will be the de facto standard to gain privileges, as sudo is now, and
having a group sudoroot whose members are allowed to gain to become root
using an imaginary suto command sounds wrong.

> Really, ideally, this is something that would be standardized across
> distributions.

I think, especially if we think about cross distribution standardisation
we should choose a name that is independent from implementation details
like command names.


The subject of this thread summarizes the purpose of this group quite
well:

... / distinct group for users with administrative privileges
^^^^^ ^^^^^^^^^^

As admin already has been discussed and some people raised possible
disadvantages, what about using an abbreviation of the word privileges,
i.e., priv as group name?

> Yeah, that's the argument for using something relatively obscure, ...

priv should be obscure enough


Carsten


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20101021225641.GA11785@foghorn.stateful.de">http://lists.debian.org/20101021225641.GA11785@foghorn.stateful.de
 
Old 10-21-2010, 11:53 PM
Bob Proulx
 
Default disabled root account / distinct group for users with administrative privileges

Giacomo A. Catenazzi wrote:
> Simon McVittie wrote:
> >... so in practice, staff is root-equivalent, but in principle it's
> >not meant to be. (Yay.)
>
> It depends on the definition of "equivalent".
>
> Anyway "staff" is a protection against user (aka admin)* errors*,
> not against *malicious* admins.

I expect group staff to have write access to /usr/local so that
'./configure && make && make install' can install software in
/usr/local but bad software that tries to write to /etc/ will be
prevented by filesystem permissions. It is there to create a safety
net. I use that feature personally even though I have superuser
access because I am less likely to make a costly mistake.

Also in practice this means that I can assign someone to the staff
group and they can be quite well enabled to do things but not
ultimately enabled to break things. Sure they can try a social
engineering attack against root to break in but I try to avoid working
with such antisocial people. The 'staff' group is a useful shade of
grey that lives between the black and the white.

I think it would be bad to overload the 'staff' group for other
meanings.

Bob

P.S. I wish other distros would pick up the 'staff' model. It is one
of the things I sometimes set up myself when working on other systems
that don't have it.
 
Old 10-22-2010, 10:44 AM
Ian Jackson
 
Default disabled root account / distinct group for users with administrative privileges

Carsten Hey writes ("Re: [RFC] disabled root account / distinct group for users with administrative privileges"):
> A group named sudo or sudoroot is somehow linked to sudo as tool used to
> gain administrative privileges. No one knows if in future an other tool
> will be the de facto standard to gain privileges, as sudo is now, and
> having a group sudoroot whose members are allowed to gain to become root
> using an imaginary suto command sounds wrong.

Speaking as the author of a program ("really") which would also want
to use the same group, I have no problem at all with a group name
which mentions sudo specifically. This is probably the best way to
ensure that the name is meaningful and not used elsewhere for
something else.

"sudoroot" is better than "sudo", as there already is a sudo group and
therefore people may already be using it for something else.

> As admin already has been discussed and some people raised possible
> disadvantages, what about using an abbreviation of the word privileges,
> i.e., priv as group name?

I wouldn't be at all surprised to find that "priv" was occasionally
used as a username for an ordinary user.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 19649.27407.817579.336069@chiark.greenend.org.uk"> http://lists.debian.org/19649.27407.817579.336069@chiark.greenend.org.uk
 
Old 10-22-2010, 11:04 AM
Simon McVittie
 
Default disabled root account / distinct group for users with administrative privileges

On Thu, 21 Oct 2010 at 17:53:53 -0600, Bob Proulx wrote:
> Giacomo A. Catenazzi wrote:
> > It depends on the definition of "equivalent".

The definition of root-equivalent I'd use is: if an account is compromised (an
attacker gains control of it), and the attacker can get root privileges as a
result, then that account is root-equivalent.

(Privilege-escalation bugs like CVE-2010-2961 make every account
accidentally root-equivalent, which is why it's so important to fix them!)

For instance, group 'sudo' (or 'admin' on Ubuntu) is root-equivalent by
design (although it's a little awkward for an attacker, because they'd have
to insert a trojanned sudo binary into the $PATH and wait for the user to
sudo again in order to get their password). Group 'disk' is more directly
root-equivalent, because you can (for instance) copy /bin/sh to your home
directory and use debugfs to make it setuid-root.

> I expect group staff to have write access to /usr/local so that
> './configure && make && make install' can install software in
> /usr/local but bad software that tries to write to /etc/ will be
> prevented by filesystem permissions.

That's a useful safety net against mistakes, but 'staff' is still
root-equivalent (because it can insert things into root's $PATH). To add
someone to 'staff', you need to trust them not to abuse their ability to
get root (you've said you do trust them that far, so that's fine), and you
*also* need to trust them not to let someone less principled break into their
account (insufficiently good password, stolen laptop, login over telnet,
unintentionally running malicious software, whatever).

Simon


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20101022110402.GB25320@reptile.pseudorandom.co.uk" >http://lists.debian.org/20101022110402.GB25320@reptile.pseudorandom.co.uk
 

Thread Tools




All times are GMT. The time now is 05:01 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org