Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Guido Günther]

On Tue, Nov 02, 2010 at 05:47:45PM +, Ian Jackson wrote:
> Guido Günther writes ("Re: [RFC] disabled root account / distinct group for 
> users with administrative privileges"):
> > Imho we should use diffrent groups for PolicyKit and sudo. d-i would
> > need to add the user to two groups then but it would allow for polkit
> > and sudo only configurations:
> 
> Why should we use different groups ?  I'm not familiar with PolicyKit,
> but does it provide equivalent access to sudo ?  If it does, why would
> admins often want to provide one path but not the other ?

PolicyKit has the concept of AdminIdentities that can be used to
authenticate whenever administrator authentication is required. If a
certain action requires auth_admin or not is governed by the policy.

If we only want to add rootlike access (which is of course required if
the root account is diabled) we could use the same group for sudo and
polkit but if we want to go further by e.g. not prompting for a password
for certain actions we should use a different role (group) to
differentiate this. 

So we should make it very clear to the user that the groups sole purpose
is to replace the functionality of the disabled root account and nothing
else. Something like "root-equiv" comes to mind. Things like "admin"
sound to generic.
Cheers,
 -- Guido


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101103092815.ga22...@bogon.sigxcpu.org

Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Ian Jackson]

Guido Günther writes ("Re: [RFC] disabled root account / distinct group for 
users with administrative privileges"):
> Imho we should use diffrent groups for PolicyKit and sudo. d-i would
> need to add the user to two groups then but it would allow for polkit
> and sudo only configurations:

Why should we use different groups ?  I'm not familiar with PolicyKit,
but does it provide equivalent access to sudo ?  If it does, why would
admins often want to provide one path but not the other ?

(Of course if they don't want to do it often then it's OK to have just
one group, because the admin can set up their own group with their own
config in just sudo, say, if they want.)

Ian.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/19664.20161.108361.829...@chiark.greenend.org.uk

Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Guido Günther]

On Tue, Oct 19, 2010 at 12:38:41AM +0200, Michael Biebl wrote:
> Hi,
> 
> as some of you might know, the debian installer allows to install a system 
> with
> a disabled root account, i.e. there is no root password set for root.
> In lenny, iirc, this was done via d-i pre-seeding, in squeeze it is as simple 
> as
> leaving the root password prompt empty.
> 
> The lenny installer then added the user, that was created during install, to
> /etc/sudoers to grant him administrative privileges.
> 
> For squeeze we looked for a better way, especially as PolicyKit is becoming 
> used
> by more and more packages and mangling the PolicyKit configuration didn't look
> like a sane alternative.
> 
> The idea is, to have a distinct group. Members of that group have 
> administrative
> privileges using sudo and PolicKit. The installer then simply has to add the

Fedora introduced desktop_admin_r for this in the polkit-destkop-polcy
package:

http://www.redhat.com/archives/fedora-desktop-list/2009-August/msg00103.html

Imho we should use diffrent groups for PolicyKit and sudo. d-i would
need to add the user to two groups then but it would allow for polkit
and sudo only configurations:

If you only want to grant polkit based privileges remove the user from
the sudoers group and if you only want sudo based privileges remove it
from the desktop_admin_r group. This would allow administrators to only
care about one set of privileges which makes it easier to oversee the
consequences when adding more users to these groups.
Cheers,
 -- Guido

> user to that group, if installed in root-disabled mode.
> The relevant bug reports for PolicyKit is [1], the one for user-setup [2].
> 
> 
> Bdale went ahead and added the following to /etc/sudoers:
> 
> # Allow members of group sudo to not need a password
> # (Note that later entries override this, so you might need to move
> # it further down)
> %sudo ALL=(ALL) ALL
> 
> 
> The installer was changed to add the user to group "sudo" if the system is
> installed with root disabled.
> 
> For PolicyKit, I can now simply ship a file, say
> /etc/polkit-1/localauthority.conf.d/51-debian-sudo.conf which contains:
> 
> [Configuration]
> AdminIdentities=unix-group:sudo
> 
> 
> 
> While I think the idea of using a distinct group for users with administrative
> privileges is a very good one, I'm not sure if using the group name "sudo" is
> the right choice, for two reasons:
> 
> 1/ The sudo group in previous Debian releases had a different meaning: Members
> of groups sudo could run sudo without needing a password.
> 
> 2/ Using the name sudo in context of PolicyKit sounds weird and misleading.
> 
> 
> 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.
> 
> I'm a bit undecided atm. While I lean towards using a new group and in that 
> case
> the name "admin", I also know that we are already late in the squeeze release
> cycle and picking a new name will require changes to user-setup and sudo.
> policykit-1 hasn't being updated yet, so it'll require a new upload anyway.
> 
> Bdale was open to changing the sudo configuration, but he didn't want to drive
> this discussion.
> 
> I'm very much interested in your feedback on this matter and what others think
> is the best way to go and if there is maybe another, even better suggestion 
> for
> this group name.
> 
> I've also CCed debian-release as I want to know if they'd ack uploads of the
> affected packages.
> 
> 
> Cheers,
> Michael
> 
> 
> 
> 
> 
> 
> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=536490
> [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=597239
> -- 
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> 



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101101143931.ga10...@bogon.sigxcpu.org

Re: History ...: [RFC] disabled root account / distinct group for users with administrative privileges

[Osamu Aoki]

Hi,

My concern was random introduction of more new groups with confusing
names and overwrapping capabilities with inconsistent documentation.  

Besides, it sounded funny to say "reinvent the wheel".

On Sun, Oct 24, 2010 at 09:22:10PM +0100, Simon McVittie wrote:
> On Sun, 24 Oct 2010 at 18:05:45 +0900, Osamu Aoki wrote:
> > (Let's use old "wheel" group in line with current documentations.)
> 
> That's not in line with wheel's historical use, though... historically
> wheel meant "may run su(8) at all". Everyone on a GNU system has the
> privileges traditionally given to the wheel group - they can su to any
> other user *whose password they also know*, including root.
> 
> (The section you cited in the coreutils info page also mentions needing to
> know the root password.)

As for the password used, you are right.

I cited these since this discussion was titles as "users with
administrative privileges".
 
> The required group in this thread is "can become root by using *their own*
> password, without knowing the root password" - i.e. sudo on current Debian
> or admin on current Ubuntu.

It is true current default /etc/sudoers created by postinst already
contains %sudo.  So we have already reinvented the "wheel" by choosing
"sudo" for users with administrative privileges in Debian via sudo
package. 

(Ubuntu's sudo also seems set %sudo group in the same way in its
postinst as I checked maverick. Interesting.)

It may be good idea to update the documented example in sudoers(5) from
"wheel" to "sudo" in line with what we do.

Osamu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101025145250.ga4...@debian.org

Re: History ...: [RFC] disabled root account / distinct group for users with administrative privileges

[Simon McVittie]

On Sun, 24 Oct 2010 at 18:05:45 +0900, Osamu Aoki wrote:
> (Let's use old "wheel" group in line with current documentations.)

That's not in line with wheel's historical use, though... historically
wheel meant "may run su(8) at all". Everyone on a GNU system has the
privileges traditionally given to the wheel group - they can su to any
other user *whose password they also know*, including root.

(The section you cited in the coreutils info page also mentions needing to
know the root password.)

The required group in this thread is "can become root by using *their own*
password, without knowing the root password" - i.e. sudo on current Debian
or admin on current Ubuntu.

S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101024202210.gb20...@reptile.pseudorandom.co.uk

History ...: [RFC] disabled root account / distinct group for users with administrative privileges

[Osamu Aoki]

Hi,

Let's not reinvent the "wheel" :-)

(Let's use old "wheel" group in line with current documentations.)

On Sat, Oct 23, 2010 at 09:44:41PM +0200, Arthur de Jong wrote:
> On Thu, 2010-10-21 at 16:48 +0100, Philip Hands wrote:
> > 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'.

Very true.
 
> > 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.
> 
> The admin group is already used in update-notifier though (#502392) and
> perhaps also other software coming from Ubuntu.

If we talk about previous practices, the use of "wheel" predates "admin"
to describe group for users with administrative privileges.  This fact
can be seen many current core packages although they are mostly in
documentation only, thanks to RMS.  Let me list few references.

Most notable on is still in our current squeeze "info su" as:

| 23.6.1 Why GNU `su' does not support the `wheel' group
| --
| 
| (This section is by Richard Stallman.)
| ...

Since we use PAM version of su in Debian, this is not true.  But it
clearly states "wheel" group is intended for such use.  

The current su can be configured to support the "wheel" group now as
described in /etc/pam.d/su despite RMS's wish.

| # Uncomment this to force users to be a member of group root
| # before they can use `su'. You can also add "group=foo"
| # to the end of this line if you want to use a group other
| # than the default "root" (but this may have side effect of
| # denying "root" user, unless she's a member of "foo" or explicitly
| # permitted earlier by e.g. "sufficient pam_rootok.so").
| # (Replaces the `SU_WHEEL_ONLY' option from login.defs)
| # auth   required   pam_wheel.so
 
Here, the use of "root" group is implied.  It could be made to use the "wheel"
group as long as root is also its member.  Odd old history of GNU by RMS
here.

In the current sudoers(5) manpage, the use of "wheel" group is also implied
for as such root access group in its example.

|   The User specification is the part that actually determines who may run
|   what.
|root   ALL = (ALL) ALL
|%wheel ALL = (ALL) ALL
|   We let root and any user in group wheel run any command on any host as
|   any user.

As I see in http://en.wikipedia.org/wiki/Wheel_(Unix_term) , the "wheel"
group seems most traditional name for such administrative privileges
from pre-Unix days.  (I thought wheel  was from BSD thing but these are
much older.)

So let us not to reinvent a new group name.  Let's use old "wheel" group.

Whatever we choose, it may be good idea to have some consistency across
our system and documentation.

Osamu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101024090545.ga10...@debian.org

Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Arthur de Jong]

On Thu, 2010-10-21 at 16:48 +0100, Philip Hands wrote:
> 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'.

At work we use "admin" to hold all administrative staff (think
paperwork) so I would vote against that.

> 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.

The admin group is already used in update-notifier though (#502392) and
perhaps also other software coming from Ubuntu.

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part

Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Carsten Hey]

* Simon McVittie [2010-10-22 12:10 +0100]:
> On Fri, 22 Oct 2010 at 11:44:31 +0100, Ian Jackson wrote:
> > I wouldn't be at all surprised to find that "priv" was occasionally
> > used as a username for an ordinary user.
>
> If I saw it out of context I'd also tend to assume that "priv" is
> short for "private" instead of "privileged", but perhaps that's just
> me.

No, it isn't just you, I thought that it could also mean 'private', too.
'prvl' or similar would look like it would have been generated by pwgen.

It doesn't look like a short, unambiguous and pronounceable abbreviation
for 'privileged' exists and 'sysadmins' seems to be a better choice than
'privileged' or 'privileges'.

My favorites up to now are 'sysadmins' and 'sudoroot', although I don't
like having the command as part of the groupname.


Carsten


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101022174232.ga17...@foghorn.stateful.de

Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Teodor MICU]

On Fri, Oct 22, 2010 at 1:44 PM, Ian Jackson
 wrote:
> 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.

I'm proposing to use 'sysadmins' (plural as 'users') since its kinda
short and commonly accepted for this purpose on job announcements.

Thanks


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktin7qzt_gdxgpkrv0oawo9gqdprjboy1n3mdk...@mail.gmail.com

Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Simon McVittie]

On Fri, 22 Oct 2010 at 11:44:31 +0100, Ian Jackson wrote:
> I wouldn't be at all surprised to find that "priv" was occasionally
> used as a username for an ordinary user.

If I saw it out of context I'd also tend to assume that "priv" is short for
"private" instead of "privileged", but perhaps that's just me.

S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101022111055.gc25...@reptile.pseudorandom.co.uk

Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Simon McVittie]

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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101022110402.gb25...@reptile.pseudorandom.co.uk

Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Ian Jackson]

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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/19649.27407.817579.336...@chiark.greenend.org.uk

Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Bob Proulx]

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.


signature.asc
Description: Digital signature

Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Carsten Hey]

* 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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101021225641.ga11...@foghorn.stateful.de

Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Giacomo A. Catenazzi]

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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4cc0637b.7070...@debian.org

Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Philip Hands]

On Thu, 21 Oct 2010 06:49:00 +0200, Christian PERRIER  
wrote:
> Quoting Russ Allbery (r...@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


pgpeIBAuPRdqM.pgp
Description: PGP signature

Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Russ Allbery]

Christian PERRIER  writes:
> Quoting Russ Allbery (r...@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 (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871v7j7upk@windlord.stanford.edu

Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Michael Banck]

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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101021090336.ge32...@nighthawk.chemicalconnection.dyndns.org

Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Ben Finney]

Christian PERRIER  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


pgphH5N2aTFAU.pgp
Description: PGP signature

Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Christian PERRIER]

Quoting Russ Allbery (r...@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




signature.asc
Description: Digital signature

Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Russ Allbery]

Christian PERRIER  writes:
> Quoting Steve Langasek (vor...@debian.org):

>>> On the other hand, is it really necessary a new group?  Can't adm or
>>> operator be overloaded with this new functionality? (think Ockham's
>>> razor).

>> No.  Both of those groups also have other meanings.

> 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
group 0 (which happens to be root on Debian), a policy that for us dates
back to when we were a Solaris shop, and then set su and ksu so that
they're only executable by users in the root group.  This limits access to
su/ksu, but not in the same way that is being discussed here for sudo.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87eibkfr55@windlord.stanford.edu

Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Julien Cristau]

On Wed, Oct 20, 2010 at 17:38:23 +0200, Didier 'OdyX' Raboud wrote:

> Otavio Salvador wrote:
> 
> > Maybe "god" ;-)
> 
> What about the "adm" group ? Is it the same as the "admin" ?
> 
What about reading the thread and relevant documentation instead of
repeating turned down ideas for the bikeshed colour?

Cheers,
Julien


signature.asc
Description: Digital signature

Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Otavio Salvador]

Maybe "god" ;-)

On Wed, Oct 20, 2010 at 8:16 AM, Mehdi Dogguy  wrote:
> On 20/10/2010 11:18, Petter Reinholdtsen wrote:
>>
>> So I would suggest to use a name that is more likely to be unique.
>>
>
> unique wrt. what? "admin" seems "unique" since not used in Debian yet.
>
>> Happy hacking,
>
> --
> Mehdi Dogguy مهدي الدڤي
> http://dogguy.org/
>
>
> --
> To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: http://lists.debian.org/4cbec179.6030...@dogguy.org
>
>



-- 
Otavio Salvador                  O.S. Systems
E-mail: ota...@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854         http://projetos.ossystems.com.br


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlkti=vdves+9hmzv4bsuxxl03zmqriqir2gbptd...@mail.gmail.com

Re: [RFC] disabled root account / distinct group for users with administrative privileges

[The Fungi]

On Wed, Oct 20, 2010 at 12:28:49PM +0100, Simon McVittie wrote:
> Quoting from base-passwd again:
[...]
> ... so in practice, staff is root-equivalent, but in principle it's not meant
> to be. (Yay.)

Right, which was why I also chose to use it for "staff" who I
trusted with root access, but wanted logging in with their own user
IDs and making most changes through sudo (so that there's an audit
trail in case they accidentally break something I later have to
fix).
-- 
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101020144644.gf8...@yuggoth.org

Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Simon McVittie]

On Wed, 20 Oct 2010 at 01:58:22 +, The Fungi wrote:
> On Tue, Oct 19, 2010 at 09:48:58AM +0200, Jesús M. Navarro wrote:
> > On the other hand, is it really necessary a new group?  Can't adm
> > or operator be overloaded with this new functionality? (think
> > Ockham's razor).
> 
> Maybe similarly overloaded, but I've used the built-in "staff" group
> for this for many years. It already gets write access into many
> local system folders by default, so not that much of a stretch...

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.)

S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101020112849.ga14...@reptile.pseudorandom.co.uk

Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Mehdi Dogguy]

On 20/10/2010 11:18, Petter Reinholdtsen wrote:
> 
> So I would suggest to use a name that is more likely to be unique.
> 

unique wrt. what? "admin" seems "unique" since not used in Debian yet.

> Happy hacking,

-- 
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4cbec179.6030...@dogguy.org

Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Bernhard R. Link]

* Vincent Danjean  [101020 09:46]:
> > How about the "root" group?
>
> This would hurt systems where umask is 002 (or 007) by default (the root
> group is the primary group of the root user with nobody else in it)

No, the root group (aka wheel) group is the group of people that are
allowed to switch to root if not everyone allowed to (pam_wheel, ...).

Nothing should assume that on a random system only root is in group
root.

Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101020084744.ga16...@pcpool00.mathematik.uni-freiburg.de

Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Vincent Danjean]

[reply-to set to d-d only]

On 20/10/2010 07:12, Christian PERRIER wrote:
> Quoting Steve Langasek (vor...@debian.org):
> 
>>> On the other hand, is it really necessary a new group?  Can't adm or 
>>> operator 
>>> be overloaded with this new functionality? (think Ockham's razor).
>>
>> No.  Both of those groups also have other meanings.
> 
> 
> How about the "root" group?

This would hurt systems where umask is 002 (or 007) by default (the root
group is the primary group of the root user with nobody else in it)

  Regards,
Vincent

-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4cbe9e22.5070...@free.fr

Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Christian PERRIER]

Quoting Steve Langasek (vor...@debian.org):

> > On the other hand, is it really necessary a new group?  Can't adm or 
> > operator 
> > be overloaded with this new functionality? (think Ockham's razor).
> 
> No.  Both of those groups also have other meanings.


How about the "root" group?




signature.asc
Description: Digital signature

Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Steve Langasek]

On Tue, Oct 19, 2010 at 09:48:58AM +0200, Jesús M. Navarro wrote:
> On Tuesday 19 October 2010 08:15:56 Josselin Mouette wrote:
> [...]

> > Le mardi 19 octobre 2010 à 02:12 +0200, Jesús M. Navarro a écrit :
> > > What about the old-fashioned "wheel" group[1]?

> > This would be an even worse disaster than “admin”, for similar reasons.
> > Users of the “wheel” group were not supposed to get root privileges with
> > their own password.

> Ok.  But since this group is conceptually the same than the "old" wheel 
> group, 
> one "that provides additional special system privileges that empower a user 
> to execute restricted commands that ordinary user accounts cannot access", 
> why not make a bit of a joke of it?  How about bigwheel (since that's where 
> wheel derives from)?

It is *semantically* different.  The worst possible way to implement this is
by overtaking a pre-existing group that *we have defined* to have different
semantics than what it's being proposed for.

Defining a new group that may conflict with existing local groups on
particular installed systems is not much better, but it's as good as we can
get.

> On the other hand, is it really necessary a new group?  Can't adm or operator 
> be overloaded with this new functionality? (think Ockham's razor).

No.  Both of those groups also have other meanings.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: [RFC] disabled root account / distinct group for users with administrative privileges

[The Fungi]

On Tue, Oct 19, 2010 at 09:48:58AM +0200, Jesús M. Navarro wrote:
[...]
> On the other hand, is it really necessary a new group?  Can't adm
> or operator be overloaded with this new functionality? (think
> Ockham's razor).

Maybe similarly overloaded, but I've used the built-in "staff" group
for this for many years. It already gets write access into many
local system folders by default, so not that much of a stretch...
-- 
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101020015820.ge8...@yuggoth.org

Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Simon McVittie]

base-passwd documents sudo as "Members of this group do not need to type their
password when using sudo", which is no longer true. I've opened a bug.

On Tue, 19 Oct 2010 at 09:48:58 +0200, Jesús M. Navarro wrote:
> On the other hand, is it really necessary a new group?  Can't adm or operator 
> be overloaded with this new functionality? (think Ockham's razor).

/usr/share/doc/base-passwd/users-and-groups.txt.gz documents the meanings of
the predefined groups and whether they are root-equivalent.

In particular, adm is not meant to be root-equivalent. Members can read
potentially-sensitive system logfiles, but no more:

Group adm is used for system monitoring tasks. Members of this group can
read many log files in /var/log, and can use xconsole.

Historically, /var/log was /usr/adm (and later /var/adm), thus the name of
the group.

HELP: Perhaps policy should state the purpose of this group so users may be
safely added to it, in certainty that all they'll be able to do is read
logs. Wouldn't hurt to rename it 'log' either ...

On some machines I use, sysadmins' "mere mortal" user IDs are in group adm
(so after a normal login, a sysadmin is only slightly privileged - they
can read the logs), but to actually gain root, the sysadmin must log in with a
different SSH key, which is an authorized key for a privileged user with uid 0,
named something lik smcvR.

This is to avoid having the user's "mere mortal" login already be
root-equivalent, which is inconvenient/excessive for personal machines, but
good for a server environment.

(On a machine where I can sudo, anyone who can take over my normal account can
get root next time I use sudo, by putting a trojan sudo into my $PATH and
capturing my password. On a machine where I have a separate smcvR account for
being root, I lose a bit of convenience (although not much, if I'm logging in
remotely anyway), but an attacker would have to gain control of smcvR to do
serious damage.)

Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101019112424.gc13...@reptile.pseudorandom.co.uk

Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Olaf Mandel]

Am Dienstag, den 19.10.2010, 08:15 +0200 schrieb Josselin Mouette:
> Le mardi 19 octobre 2010 à 00:38 +0200, Michael Biebl a écrit : 
-Snipp-
> > 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.
> 
> “admin” is a very widespread group name, this is likely to cause huge
> security issues if members of this group are not supposed to be granted
> root privileges.
-Snipp-

Hi,

just a short info from one of the derivative distros: in Ubuntu, the
user-setup-udeb adds the following text to sudoers (and creates the
admin group, if it doesn't exist):

--Cut here--

# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL
--Cut here--

The newest Debian equivalent (1.34) adds the user to the sudo group if
possible while the older version (1.23) hardcodes the username in
sudoers. 

Personally, I think using the sudo (or the admin) group in Debian would
probably be fine:

* the current sudo package seems to by default support members of the
sudo group as being able to execute arbitrary commands after typing in
their own password
* which different expectations do users have on the sudo group?
* the admin group would not be necessary (at least since sudo by default
uses the sudo group)
* On the other hand, adding a third group might be incompatible with
other distros.

My 2ct,
Olaf Mandel


signature.asc
Description: This is a digitally signed message part

Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Philip Hands]

On Tue, 19 Oct 2010 00:38:41 +0200, Michael Biebl  wrote:

> Bdale went ahead and added the following to /etc/sudoers:
> 
> # Allow members of group sudo to not need a password
> # (Note that later entries override this, so you might need to move
> # it further down)
> %sudo ALL=(ALL) ALL

Ah yes -- that's a bug in the comment of course.

The comment says (incorrectly) that people in the sudo group don't need
a password.  It would need a NOPASSWD tag for the comment to be correct.

Thankfully, the configuration does the right thing, and requires that
the user know their own password to become root.

> The installer was changed to add the user to group "sudo" if the system is
> installed with root disabled.
> 
> For PolicyKit, I can now simply ship a file, say
> /etc/polkit-1/localauthority.conf.d/51-debian-sudo.conf which contains:
> 
> [Configuration]
> AdminIdentities=unix-group:sudo

I would object to 'sudo' being a group of people that can simply become
root if they happen to be logged in -- is that what the PolicyKit
incantation would allow?

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


pgpZEcT01WzH1.pgp
Description: PGP signature

Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Josselin Mouette]

Le mardi 19 octobre 2010 à 09:58 +0100, Philip Hands a écrit :
> > For PolicyKit, I can now simply ship a file, say
> > /etc/polkit-1/localauthority.conf.d/51-debian-sudo.conf which contains:
> > 
> > [Configuration]
> > AdminIdentities=unix-group:sudo
> 
> I would object to 'sudo' being a group of people that can simply become
> root if they happen to be logged in -- is that what the PolicyKit
> incantation would allow?

No, it leads to them being able to do PolicyKit actions (such as
formatting a disk or changing a system default) that require root
privileges, with entering their own password. Just as sudo does without
NOPASSWD.

Cheers,
-- 
 .''`.
: :' : “You would need to ask a lawyer if you don't know
`. `'   that a handshake of course makes a valid contract.”
  `---  J???rg Schilling


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1287479240.10136.10.ca...@meh

Re: Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Josselin Mouette]

Le mardi 19 octobre 2010 à 09:49 +0200, Fabian Greffrath a écrit :
> Since this group would be Debian-specific, how about "Debian-admin" or 
> "Debian-sudo" (as in "Debian-gdm" or "Debian-exim")?

The Debian-exim and Debian-gdm names are system users that are meant to
never conflict with existing, non-system users, hence the choice of
nonstandard names. OTOH the sudo group is meant to be handled by e.g. a
LDAP directory, so you have to use a standard name.

Cheers,
-- 
 .''`.
: :' : “You would need to ask a lawyer if you don't know
`. `'   that a handshake of course makes a valid contract.”
  `---  J???rg Schilling


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1287476120.10136.7.ca...@meh

Re: Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Fabian Greffrath]

I definitely agree that we need to get this change into squeeze and that we need
to be careful to not get into bikeshedding about names.

On the other hand, choosing a group for a purpose like this should imho be done
carefully as changing the name later is hard if not impossible.


Since this group would be Debian-specific, how about "Debian-admin" or 
"Debian-sudo" (as in "Debian-gdm" or "Debian-exim")?


 - Fabian


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4cbd4d94.2070...@greffrath.com

Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Jesús M. Navarro]

Hi, Josselin:

On Tuesday 19 October 2010 08:15:56 Josselin Mouette wrote:
[...]

> Le mardi 19 octobre 2010 à 02:12 +0200, Jesús M. Navarro a écrit :
> > What about the old-fashioned "wheel" group[1]?
>
> This would be an even worse disaster than “admin”, for similar reasons.
> Users of the “wheel” group were not supposed to get root privileges with
> their own password.

Ok.  But since this group is conceptually the same than the "old" wheel group, 
one "that provides additional special system privileges that empower a user 
to execute restricted commands that ordinary user accounts cannot access", 
why not make a bit of a joke of it?  How about bigwheel (since that's where 
wheel derives from)?

On the other hand, is it really necessary a new group?  Can't adm or operator 
be overloaded with this new functionality? (think Ockham's razor).

Cheers.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201010190948.58805.jesus.nava...@undominio.net

Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Michael Biebl]

On 19.10.2010 08:15, Josselin Mouette wrote:
> Le mardi 19 octobre 2010 à 00:38 +0200, Michael Biebl a écrit : 
>> 1/ The sudo group in previous Debian releases had a different meaning: 
>> Members
>> of groups sudo could run sudo without needing a password.
> 
> Did it exist in previous releases? I don’t recall seeing it in sudoers.

Bdale certainly knows the gory details and can tell us more.

But afaicr, sudo was compiled with EXEMPT_GROUP sudo in previous releases.

Bdale, please speak up if I tell non-sense here. Can you tell us a bit more
about the history of group sudo, please.


> I think it’s much more important to get this change into squeeze than to
> bikeshed the group name.

I definitely agree that we need to get this change into squeeze and that we need
to be careful to not get into bikeshedding about names.

On the other hand, choosing a group for a purpose like this should imho be done
carefully as changing the name later is hard if not impossible.

I'm sorry if I sound a bit overly cautious here and maybe my concerns are
unfounded. But that's the reason why I brought this up on debian-devel.


Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Bjoern Meier]

hi,


2010/10/19 Michael Biebl :
> Hi,
> Bdale went ahead and added the following to /etc/sudoers:
>
> # Allow members of group sudo to not need a password
> # (Note that later entries override this, so you might need to move
> # it further down)
> %sudo ALL=(ALL) ALL

First of all: YES! Thanks! I didn't know the possibility of an install
with disabled root-login.
I use DebIan 90% in a professionell environment and disable root login
by hand. So yes, I would prefer an administrative group and would say:
disabled root login as default (like logins on GDM).
I don't like the idea to do sudo-things without password. I like it to
pass my secret, because this is a hint, that I do something
system-related. So: I think we need a password here.

> 1/ The sudo group in previous Debian releases had a different meaning: Members
> of groups sudo could run sudo without needing a password.
>
> 2/ Using the name sudo in context of PolicyKit sounds weird and misleading.

Yes, sudo is not a good name for an admin group.
Well, admin also, because "Domain admin", "admin" "and
"administrators" are to near to windows. I use winbind to get the
groups out of the active directory and would prefer unique names for
groups.
My suggestions are:

- debadm
- linad (linux-administrator)
- uwscp (just a joke: user-with-super-cow-powers; a lean to "his APT
has Super Cow Powers." ;) )

Greetings,
Björn


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktik0ped_eemqnnkn0rcabt84hqd4ztppjprwq...@mail.gmail.com

Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Josselin Mouette]

Le mardi 19 octobre 2010 à 00:38 +0200, Michael Biebl a écrit : 
> 1/ The sudo group in previous Debian releases had a different meaning: Members
> of groups sudo could run sudo without needing a password.

Did it exist in previous releases? I don’t recall seeing it in sudoers.

> 2/ Using the name sudo in context of PolicyKit sounds weird and misleading.

I don’t think so, since the configuration snippet makes PK behave like
sudo.

> 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.

“admin” is a very widespread group name, this is likely to cause huge
security issues if members of this group are not supposed to be granted
root privileges.

> I'm a bit undecided atm. While I lean towards using a new group and in that 
> case
> the name "admin", I also know that we are already late in the squeeze release
> cycle and picking a new name will require changes to user-setup and sudo.
> policykit-1 hasn't being updated yet, so it'll require a new upload anyway.

I think it’s much more important to get this change into squeeze than to
bikeshed the group name.

Le mardi 19 octobre 2010 à 02:12 +0200, Jesús M. Navarro a écrit :
> What about the old-fashioned "wheel" group[1]?

This would be an even worse disaster than “admin”, for similar reasons.
Users of the “wheel” group were not supposed to get root privileges with
their own password.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'  “If you behave this way because you are blackmailed by someone,
  `-[…] I will see what I can do for you.”  -- Jörg Schilling


signature.asc
Description: This is a digitally signed message part

Re: [RFC] disabled root account / distinct group for users with administrative privileges

[Jesús M. Navarro]

Hi, Michael:

On Tuesday 19 October 2010 00:38:41 Michael Biebl wrote:
> Hi,

[...]

> The idea is, to have a distinct group. Members of that group have
> administrative privileges using sudo and PolicKit.

[...]

> While I think the idea of using a distinct group for users with
> administrative privileges is a very good one, I'm not sure if using the
> group name "sudo" is the right choice, for two reasons:
>
> 1/ The sudo group in previous Debian releases had a different meaning:
> Members of groups sudo could run sudo without needing a password.
>
> 2/ Using the name sudo in context of PolicyKit sounds weird and misleading.
>
>
> So, I'm wondering if we shouldn't pick a more neutral name without a
> previous history in Debian.

What about the old-fashioned "wheel" group[1]?

Now, prior to resurrect the 'wheel' group, please take into account why 
there's neither wheel group nor wheel support for su on GNU systems and see 
if the concerns are still valid in this new environment.

Cheers.

[1] http://en.wikipedia.org/wiki/Wheel_(Unix_term)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201010190212.25613.jesus.nava...@undominio.net

[RFC] disabled root account / distinct group for users with administrative privileges

[Michael Biebl]

Hi,

as some of you might know, the debian installer allows to install a system with
a disabled root account, i.e. there is no root password set for root.
In lenny, iirc, this was done via d-i pre-seeding, in squeeze it is as simple as
leaving the root password prompt empty.

The lenny installer then added the user, that was created during install, to
/etc/sudoers to grant him administrative privileges.

For squeeze we looked for a better way, especially as PolicyKit is becoming used
by more and more packages and mangling the PolicyKit configuration didn't look
like a sane alternative.

The idea is, to have a distinct group. Members of that group have administrative
privileges using sudo and PolicKit. The installer then simply has to add the
user to that group, if installed in root-disabled mode.
The relevant bug reports for PolicyKit is [1], the one for user-setup [2].


Bdale went ahead and added the following to /etc/sudoers:

# Allow members of group sudo to not need a password
# (Note that later entries override this, so you might need to move
# it further down)
%sudo ALL=(ALL) ALL


The installer was changed to add the user to group "sudo" if the system is
installed with root disabled.

For PolicyKit, I can now simply ship a file, say
/etc/polkit-1/localauthority.conf.d/51-debian-sudo.conf which contains:

[Configuration]
AdminIdentities=unix-group:sudo



While I think the idea of using a distinct group for users with administrative
privileges is a very good one, I'm not sure if using the group name "sudo" is
the right choice, for two reasons:

1/ The sudo group in previous Debian releases had a different meaning: Members
of groups sudo could run sudo without needing a password.

2/ Using the name sudo in context of PolicyKit sounds weird and misleading.


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.

I'm a bit undecided atm. While I lean towards using a new group and in that case
the name "admin", I also know that we are already late in the squeeze release
cycle and picking a new name will require changes to user-setup and sudo.
policykit-1 hasn't being updated yet, so it'll require a new upload anyway.

Bdale was open to changing the sudo configuration, but he didn't want to drive
this discussion.

I'm very much interested in your feedback on this matter and what others think
is the best way to go and if there is maybe another, even better suggestion for
this group name.

I've also CCed debian-release as I want to know if they'd ack uploads of the
affected packages.


Cheers,
Michael






[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=536490
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=597239
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature