[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: What I HATE about F11

2009/6/14 Richard Fearn <richardfearn gmail com>:
>> # grep -n wheel /etc/sudoers
>> 81:## Allows people in group wheel to run all commands
>> 82:# %wheel     ALL=(ALL)       ALL
>> 85:# %wheel     ALL=(ALL)       NOPASSWD: ALL
>> All you have to do is uncomment one line ;)
> That's exactly what I do, followed by:
> $ usermod -a -G wheel rich
> But wouldn't it be nice if this line was uncommented by default, and
> firstboot added the first user to this group automatically?

It might be nice, but unless we document that feature heavily and
declare that 'first' user to be administrator with big warnings all
over the place, some noob will still do something stupid.  I don't
mean stupid like 'i'm a noob and i don't know what i'm doing', but
stupid like 'i didn't know firefox had a security vulnerability that
used a hole in sudo to run stuff as root, because i was using some
silly extension'.

We would have to set up a user account that is a non root user with
extra priveleges and constant warnings to the user that i really
wonder what the advantage is to it.

The best argument against all this nonsense is like this. User space
programs are complex and there are many of them. Unless you have
audited each bit that is going to be run as a privileged user, you
should avoid runnning it as some privileged user. When you log in to a
graphical desktop environment with lots of userspace programs, they
should all be running on the least amount of privileges necessary and
furthermore confined with SELinux where possible. Seriously, who wants
to audit the entire GNOME or KDE codebase? There should never be a
user that has more privileges and also running in a graphical
environment. Ever.

The only interesting debate i've heard is over two security models
i'll call 'su' and 'sudo', for their recognized behavior. 'su'
requires the root password, and 'sudo' requires your own password. Let
me argue for one more model called 'sird'. 'sird' asks for a per user
'root' password. Each user has two passwords, one is an everyday
password and one is for actions that require root access. Currently
Fedora uses a mix of 'sudo' and 'su', and is inconsistent. Ubuntu
relies only on 'sudo' for the most part, except for certain weird
programs they haven't set up to do so, and then the experince is

The security issue here though is how do we securely give 'sudo' and
'sird' like rights to users without violating the rule i stated above?
With Fedora we require that you use the root password the first time.
This way the user has to intelligently maintain that the specified
account should be given more privileges. It's then on the user's head
to violate the rule above. Ubuntu just gives sudo to the first user
created, and since i haven't touched the brown since the beginning of
2007, i have no clue how much they alert the user to the possible
security risks.

If i can put my own 2 cents in what needs to be done here: Currently
we implement this barrier to entry via the command line. Perhaps if we
could leverage PolicyKit better so we can have an icon or control tool
for the person who installs Fedora on the machine to use the root
password to grant rights to other users. Then the administrator, aka
the person responsible for instalation, could decide whether to use
su, sudo, or sird style access.

If you're wondering what 'sird' is, it's just an arbitrary name that
sounds like third, because there would be a 'third' password. (Root =
1, User = 2, Sird = 3)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]