Allowing a desktop user to execute priviledged operations was tried
over the years with different (wrong) approaches. First, let's
summarize the old technical solutions and than explain their faults.
Finally, we'll see what better approaches are being developed or
deployed nowdays.
All legacy solutions to this problem were somehow based on SUID programs:
* The oldest (~10 years) -- A GUI around su -- KDE had kdesu, gnomes
had g<something_I_forgot>su, etc.
* Than some distros (e.g: RH, Fedora) elaborated this via some suid
wrapper (console_helper?) which used PAM to run/deny the relevant
action.
* Nowdays, we have Ubuntu, wrapping sudo in a nice GUI.
Let's see why all these solutions were wrong...
On Monday, 14 בJune 2010 20:12:43 Elazar Leibovich wrote:
> We *want *those application to constantly run in the background and prompt
> the user to take action. This is a good thing.
Wrong.
Constantly prompting the user causes a Pavlovic reaction. If you wonder
what are the results overtime -- just look at a typical Windows user:
- Press OK without reading what's written.
- If there's no OK button, than press the 'x' close button.
- If there's a RED warning, close it quicker so it will go away ;-)
- If it ask for password, give it so it will stop bothering us.
If the user was authenticated (e.g: at login time) AND is *authorized*
to do something priviledged, than normally he/she should not be
prompted for anything.
(I say *normally*. There can be exceptions, but only if they are the
*exception* and not the rule).
> But I'm not interested with extra limitations. I want to allow the user
> sudo'ing whatever he wishes,
That lead us to another problem common to all legacy approaches.
SUID root programs are considered a (sometime unavoidable) security
threat. Why? Because every bug in SUID root program is potential
root compromise.
Now, despite what I just said, every Linux user (or even Unix veteran)
can list quickly a couple of SUID root programs -- passwd, su, chsh, etc.
What all these programs have in common?
- Relatively small (code size)
- Simple functionality
- Simple inputs
- In use for many years.
Which means, that the risk of unknown security holes hiding in them
is relatively low.
Compare this with the approach, suggesting running complete desktop
applications as SUID root (with any of the legacy techniques):
- Each such application is at least an order of magnitude bigger than
the simple apps mentioned above.
- Every GUI application uses libraries which are several orders of
magnitude bigger than itself (just look via 'ldd').
- It process anychronous inputs (UI events).
- Its code base frequently change as a result of UI changes (look and feel).
What is the chance, under these terms, of NOT having bugs leading to
root exploits?
To summarize this point: the risks are similar to logging-in to your
desktop as root -- big NO-NO.
If you'll do it in modern desktops you'll have root processes running
on your desktop, talking to the outside world (browser, weather applet,
mailbox notifier, etc.)
> How did Vista "solve" this problem?
> When the a software prompts for extra permissions, the user see which
> software asked for that, and if it's digitally the application's name and
> author are displayed.
Hehe, it's so 90's...
Just for the record, we have been installing crypto-signed packages
for the last 15 years:
An amusing historical reference:
http://rikers.org/rpmbook/
contains the 1997 version of "Maximum RPM", when someone bothered
documenting it -- Search for the word 'PGP'.
[Yes, that was before 'GPG' was written. Yes, I have an old (unused
now) 'PGP' signature from that year.]
However, this is a totally orthognal issue -- trust in installed software,
which has nothing to do with the previous issue -- how a desktop user
may be authorized to execute priviledged operations.
> The user is expected to examine those details and allow the program to get
> extra privileges if he wishes (software from sun? OK it's a java update, I
> clicked on Firefox installer I expect software from Mozilla Foundation to
> prompt for permissions, unsigned software is asking for permissions after I
> clicked to update my Java - wow, that's alarming!).
You describe again the Windows software installation model, which is
flawed on so many levels:
* Each vendor has it's own policy/agenda -- remember Apple pushing
Safari in a Quicktime update?
* Each vendor has it's own private update system -- no central policy.
* Ton's of other non-security related problems:
- System integration -- zero (each vendor has its own world).
- Can you tell what will be installed before installation (not the
bla-bla written by the vendor -- the exact list of files).
- What other system-related changes are happening without your
knowledge (...registry... ooohhh it hearts...)
> Of course there are many problems with this approach (for instance let's
> sign my malware for "the Sun Inc" instead of "Sun Inc"), but it's a good
> first step.
It's a bad first step trying to fix an unfixable model:
"each vendor throws his bits on the OS, and by pure
magic the result will be a working, stable, secure operating system
and applications"
What can really be done? Tzafrir already mentioned the '*Kit' things
and I'll add the '*Manager' things as well:
* All these solutions split the problem into a client-server model
* The server is priviledged to execute the necessary operations
(e.g: configure a network interface)
* The client is a *non-priviledged* UI (desktop or cli).
* Client-server communication is over D-BUS -- which is carried
over a local socket. This is important, because the server
can authenticate the client ("who-are-you") without the need for
keys, CA's etc (the kernel is the CA ;-)
* The server checks your authorization (what you are allowed to do)
via a central policy (PolicyKit query).
The cons of these new mechanisms:
* As Tzafrir mentioned -- they are more complex if you want to understand
how they work (OTOH, the normal user simply click on the network icon
without realizing what's going on behind the scenes).
* Work different that what veterans Linux/Unix users are used to.
(yes I also prefer the command line, but these tools try to solve
problems for the desktop users).
* They are relatively new. So initially there are:
- More bugs
- Less features
The pros of the new mechanisms:
* A sane architecture for system-administration by desktop users.
Bye,
> On Mon, Jun 14, 2010 at 6:55 PM, Tzafrir Cohen <tzaf...@cohens.org.il>wrote:
>
> > On Mon, Jun 14, 2010 at 06:16:11PM +0300, Elazar Leibovich wrote:
> > > On Mon, Jun 14, 2010 at 6:04 PM, Tzafrir Cohen <tzaf...@cohens.org.il
> > >wrote:
> > >
> > > > On Mon, Jun 14, 2010 at 05:47:36PM +0300, Elazar Leibovich wrote:
> > > >
> > > > > Again, sudo is super.
> > > >
> > > > Surely it's not. Super is a sudo replacement.
> > > > http://packages.debian.org/super
> > >
> > >
> > > It is hard to find an adjective which is not a debian package yet ;-)
> > >
> > >
> > > >
> > > >
> > > > > I even considered a using it on some windows machine
> > > > > which unfortunately lack this feature. It's the Ubuntu GUI for
> > leveraging
> > > > > permisions which bothers me.
> > > > > I took a quick look of the *Kit stuff. I don't see immediately what
> > > > > ConsoleKit is doing, but indeed disabling any possibility to sudo
> > through
> > > > > the GUI, and only running a package daemon is a nice step towards a
> > > > better
> > > > > authentication scheme.
> > > > > However I don't see how is it a solution for the general problem of
> > > > > executing untrusted binaries in Desktop environment.
> > > >
> > > > It's not. Nither is sudo. It's intended to help you solve the problem
> > of
> > > > a giving a semi-trusted user partial sysadmin permissions. Different
> > > > problem.
> > > >
> > >
> > > sudo doesn't solve the problem, however it might help with solving it.
> > For
> > > instance Ubuntu uses GUI wrapper for sudo in order to try and solve the
> > > problem.
> > > And indeed we're talking about different problems.
> > > Usually for the personal computer the user is totally trusted, but the
> > > software he's installing is not always trusted. We wish to make sure
that
> > > administrative actions are initiated by the user, and not by a software
> > he's
> > > running. I've yet to hear a different solution than the Vista one.
> >
> > I really fail to understand you. Could you please state the exact
> > problem you believe needs solving and how it is solved?
> >
> > --
> > Tzafrir Cohen | tzaf...@jabber.org | VIM is
> > http://tzafrir.org.il | | a Mutt's
> > tzaf...@cohens.org.il | | best
> > tzaf...@debian.org | | friend
> >
> > _______________________________________________
> > Linux-il mailing list
> > Linux-il@cs.huji.ac.il
> > http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
> >
>
_______________________________________________
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
