<div dir="ltr"><br><br><div class="gmail_quote">On Tue, Jun 15, 2010 at 12:44 AM, Oron Peled <span dir="ltr"><<a href="mailto:oron@actcom.co.il" target="_blank">oron@actcom.co.il</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div>On Tuesday, 15 בJune 2010 09:12:53 Elazar Leibovich wrote:<br>
> Thanks for the long and detailed reply!<br>
<br>
</div>Yes, but you (probabely by mistake) replied to me only.<br>
I reply to the mailing list with your full content, so<br>
the context is not lost.<br></blockquote><div> </div><div>I apologize, but at least it's much better than doing the opposite...<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div><br>
> Just to make sure I got you correctly, you're saying that no GUI app should<br>
> ask for root privileges ever, and only known application should use root<br>
> privileges, GUI applications would then only interface them (either through<br>
> socket, or by allowing anyone to sudo this specific application).<br>
<br>
</div>Generally yes.<br>
<div><br>
> That's covers installation related software, but what about other software<br>
> which needs root privileges? Say I want to run gparted? I don't want to run<br>
> a gparted server all day long just for the time I need to run it, and I do<br>
> want to be able to run it occasionally.<br>
<br>
</div>There is no problem with activation on demand (with D-Bus it's a piece<br>
of cake).<br>
<br>
What I say is that new mechanisms have split implementation:<br>
- A priviledged bussiness logic<br>
- A non-priviledged UI<br>
<br>
BTW: this is a classic separation between interface and implementation<br>
and directly leads to other, non-security-related, advantages<br>
(e.g: multiple interfaces (console, GUI, Web-based) to the same<br>
bussiness logic).<br></blockquote><div><br></div><div>I'm all for separation between UI and implementation. However if I understand you correctly you suggest that, say, gparted authors will NOT write the implementation code which needs root access.</div>
<div>I don't think it's possible to include gazillion services for each possible application need. The software must request somehow permission to run its root-depending implementation.</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div><br>
> Vista authentication model still works, I'll be sure I'm giving root<br>
> permissions to gparted and not to something that looks like gparted.<br>
> (The flaws you mentioned in the *current* Vista model are known, but I<br>
> believe some could be addressed, some flaws you mentioned are inherent to<br>
> Windows in general, and to the sudo-like mechanism it applies).<br>
<br>
</div>I'm the last to pretend being a Windows expert. However, the latest<br>
security related happenings in Vista-7, demonstrate that not much was<br>
changed from Vista (other than some colored cellophane and few more,<br>
much needed, drivers and bug-fixes).<br>
<div><br></div></blockquote><div>[snipped] </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex"><div></div>
Comparing this to the registry is a sad joke.<br></blockquote><div><br></div><div>I'm glad to hear. If the information is stored in the user directory it is really equivalent to the various .something configuration files.</div>
<div>I don't really know gconf, however when I opened the software it looked just like regedit, and when I saw that the search function was as bad as in regedit.exe I shivered.</div><div><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div><br>
> BTW please note that authentication don't have to be done with crypto!<br>
> Unwritable file paths could do as well. If for instance you'll only allow<br>
> programs in /usr/bin/* to ask for root privileges, and the user will see the<br>
> full path of the software asking for root privileges, it provides enough<br>
> authentication. The idea is to know who's asking for root relying on things<br>
> which are more secure than the software icon, it doesn't have to be crypto.<br>
<br>
</div>You got confused:<br>
- It's not the user that need to verify that the program is "good"<br>
- It's the program that need to verify that the *user* is authorized<br>
<br></blockquote><div> We're indeed talking about different threat models.</div><div>You're talking about securing a desktop box in a typical corporate environment. Indeed in this case the user permissions must be checked each and every time he's trying to execute a program.</div>
<div>I'm (and if I understand correctly, Microsoft also considers this model) talking about securing a desktop user which owns the computer.</div><div>He always have full control, if he can touch the keyboard - he's OK.</div>
<div>However he wishes to run various softwares from various sources, and we need to minimize the risks for him. The typical PC user IMHO wants to install software from various untrusted sources. Even I'm installing various software from various sources and hope for good, I need Adobe Flash I use Google Chrome, I use IntelliJ Idea and Sun's Java, those are not available from Ubuntu. And by all means I don't think Ubuntu should package all software in the universe. It should be the developers' job.</div>
<div>I think that if Linux becomes very popular it will have to happen. I tried to convince friends many times not to install random software from the internet on their Windows desktops because this tends to make troubles, but none of them agreed. I even installed virtualbox for them to try the random software on it, but it didn't help. They need that. You can't argue with that.</div>
<div><br></div><div>There are various things which can be done, but the first thing we do, is tell him - never run as root. All his files are in danger, as well as his various email accounts. However nothing can pollute his boot record or system files or kernel.</div>
<div>However sometimes the user want to run some of his untrusted software as root, and we want to allow him to do that in a relatively secure way.</div><div><br></div><div>One thing we should NOT do is to force the user to be to authorizing the update manager to run as root, and allow any program to look like the update manager.</div>
<div>If this wouldn't happen the user might have many viruses - but all are in user space.</div><div><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<br></blockquote></div></div>