Problems of a desktop Linux distribution GUI sudo
Oron Peled
oron at actcom.co.il
Tue Jun 15 10:44:31 IDT 2010
On Tuesday, 15 בJune 2010 09:12:53 Elazar Leibovich wrote:
> Thanks for the long and detailed reply!
Yes, but you (probabely by mistake) replied to me only.
I reply to the mailing list with your full content, so
the context is not lost.
> Just to make sure I got you correctly, you're saying that no GUI app should
> ask for root privileges ever, and only known application should use root
> privileges, GUI applications would then only interface them (either through
> socket, or by allowing anyone to sudo this specific application).
Generally yes.
> That's covers installation related software, but what about other software
> which needs root privileges? Say I want to run gparted? I don't want to run
> a gparted server all day long just for the time I need to run it, and I do
> want to be able to run it occasionally.
There is no problem with activation on demand (with D-Bus it's a piece
of cake).
What I say is that new mechanisms have split implementation:
- A priviledged bussiness logic
- A non-priviledged UI
BTW: this is a classic separation between interface and implementation
and directly leads to other, non-security-related, advantages
(e.g: multiple interfaces (console, GUI, Web-based) to the same
bussiness logic).
> Vista authentication model still works, I'll be sure I'm giving root
> permissions to gparted and not to something that looks like gparted.
> (The flaws you mentioned in the *current* Vista model are known, but I
> believe some could be addressed, some flaws you mentioned are inherent to
> Windows in general, and to the sudo-like mechanism it applies).
I'm the last to pretend being a Windows expert. However, the latest
security related happenings in Vista-7, demonstrate that not much was
changed from Vista (other than some colored cellophane and few more,
much needed, drivers and bug-fixes).
> (BTW about the registery, can someone please tell me what the gconf authors
> were thinking? When I saw that the first thing I thought is "Oh no, I ran
> away from windows to hide from the dreaded registery monster, and once again
> it raises its ugly head!")
The only thing common between Windows registry and gconf is that both
create a hierarchy of options.
All the rest is exactly the opposite:
* Access to settings is via gconfd which runs as the session *user*.
This means that even if the code is as buggy as hell, it CANNOT
touch *system-wide* settings.
* No monolithic storage -- settings can be (and typically are) stored
in several locations (look at /etc/gconf/2/path)
* Storage technology backends can be selected per-location -- the
currently used backend -- XML files.
[
google for "why-the-windows-registry-sucks-technically"
an interesting article by Richard WM. Jones
]
* An application can not only get/set/query the settings, but can
also request notification when an (other) application modifies
specific settings. These notification are obviously sent by
gconfd (which is a non-priviledged process, owned by the user)
* It is not related at all to system level settings (kernel, modules,
boot control, etc). So clobbering it won't brick your system.
Comparing this to the registry is a sad joke.
> BTW please note that authentication don't have to be done with crypto!
> Unwritable file paths could do as well. If for instance you'll only allow
> programs in /usr/bin/* to ask for root privileges, and the user will see the
> full path of the software asking for root privileges, it provides enough
> authentication. The idea is to know who's asking for root relying on things
> which are more secure than the software icon, it doesn't have to be crypto.
You got confused:
- It's not the user that need to verify that the program is "good"
- It's the program that need to verify that the *user* is authorized
So if a program (e.g: /sbin/ifconfig) want to know that you are
authorized to change the host IP address, it need some form of
proof that you are not an imposter. This can be done in various
forms. For example:
- Enter a password
- Show a crypto key only you have
- Ask someone trusted (e.g: the kernel)
Your argument focuses on the reverse issue:
How the user can verify that the program is "good"
As previously explained, this problem exist only for users
that follow the Windows software model:
* Install programs from many random locations and hope for good ;-)
In the linux software model:
* All software is centrally installed from signed distro repo
Now *if* the (authorized) user already installed the software (i.e:
trusted the distro repository), why should each user on the
same system be asked if the program is trusted?
What security layer is really added here? (hint: none)
>
> On Mon, Jun 14, 2010 at 4:42 PM, Oron Peled <oron at actcom.co.il> wrote:
>
> > 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 <tzafrir at 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 <
> > tzafrir at 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 | tzafrir at jabber.org | VIM is
> > > > http://tzafrir.org.il | | a Mutt's
> > > > tzafrir at cohens.org.il | | best
> > > > tzafrir at debian.org | | friend
> > > >
> > > > _______________________________________________
> > > > Linux-il mailing list
> > > > Linux-il at cs.huji.ac.il
> > > > http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
> > > >
> > >
> >
>
More information about the Linux-il
mailing list