Re: Problems of a desktop Linux distribution GUI sudo
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 o...@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
Re: Problems of a desktop Linux distribution GUI sudo
On Tue, Jun 15, 2010 at 12:44 AM, Oron Peled o...@actcom.co.il wrote: 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. I apologize, but at least it's much better than doing the opposite... 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). 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. 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. 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). [snipped] Comparing this to the registry is a sad joke. I'm glad to hear. If the information is stored in the user directory it is really equivalent to the various .something configuration files. 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. 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 We're indeed talking about different threat models. 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. I'm (and if I understand correctly, Microsoft also considers this model) talking about securing a desktop user which owns the computer. He always have full control, if he can touch the keyboard - he's OK. 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. 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. 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. However sometimes the
Re: gcc-4.5.0 Success Story with Freecell Solver
On Monday 14 Jun 2010 12:20:03 Shlomi Fish wrote: On Monday 14 Jun 2010 02:30:24 Amos Shapira wrote: There was an item on slashdot about LLVM project, have you tested it? LLVM is http://en.wikipedia.org/wiki/Low_Level_Virtual_Machine . I've learned about it from many places, including fellow developers on IRC. I've tested it with Freecell Solver back before 18-Apr-2009, according to http://fc-solve.berlios.de/docs/distro/NEWS.html . Reading from the NEWS.html file: [quote] Added Makefile.llvm to build LLVM bitcodes from the Freecell Solver sources. So far, they seem significantly slower than the native code compiled using gcc-4.3.2. [/quote] So that's it. I've used it with a binary distribution of gcc-for-LLVM instead of clang (which wasn't very mature back then). It's possible it has improved since then in this regard. In one comment I've read somewhere, it was claimed that Apple tends to hype LLVM, because that's what they support, but the fact is that gcc is much more mature and has many more years of development behind it. OK, found this comment now: http://lwn.net/Articles/391557/ Reading from it: [quote] Actually they [= Apple] just refuse to touch anything GPLv3-related. And they often oversell LLVM because they compare it with years-old GNU stuff. This is really sad because LLVM is great - it's just not as great as Apple PR guys claim... [/quote] Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ The Human Hacking Field Guide - http://shlom.in/hhfg God considered inflicting XSLT as the tenth plague of Egypt, but then decided against it because he thought it would be too evil. Please reply to list if it's a mailing list post - http://shlom.in/reply . ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: [not entirely OT] proper terms for grades of freedom
On 6/10/10, Tzafrir Cohen tzaf...@cohens.org.il wrote: On Thu, Jun 10, 2010 at 02:04:29PM +0300, Oleg Goldshmidt wrote: Is there an official term for software that comes with source code but does not allow one to modify or distribute it (modified or not)? [This was the original question that fueled my curiosity.] By giving up any of those freedoms, it means you give up on using free software. I know. The terms I am asking about will most definitely not classified as either free or open source SW. The subject of my friend's email to me was not open source software ;-). Are there licenses that provide the code but do not allow (even private) modifications? http://creativecommons.org/licenses/by-nd/3.0/ http://creativecommons.org/licenses/by-nc-nd/3.0/ Yes, but both allow distribution, so they didn't fit because of that. Sure. What you want is certainly not close to being free software. You need not bother looking there. I did not look specifically for free/open source. I looked for license comparison lists hoping to find examples (that would not be FOSS). Finally, I did mark the post OT, I posted the question here because this is a place where there are people very well versed in the subject. -- Oleg Goldshmidt | o...@goldshmidt.org ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Migrating kde data from kde3 to kde4
On 6/13/10, Stan Goodman stan.good...@hashkedim.com wrote:
If it were not for the great difference between the two kde versions, I
would simply carry over the .kde directory, and be assured that I had
captured all the data. But the v11.1 system contains both .kde and .kde4
directories, and I am not at all sure of how they interrelate.
FWIW: at some point I surely went through the KDE3-KDE4 move (on
Fedora) and I do not recall it ever affecting me. I keep /home on a
separate partition, so when I upgrade the system it remains intact.
Since I don't recall doing anything specific I suspect that either no
directory names needed to be changed or the update took care of
everything. I don't see any ~/.kde{3,4} directories on any of my
machines (on 4.4.{2,3} now), so everything was transparent (and I
don't recall anything breaking in KDE).
Of course, maybe it is just thanks to some RedHat/Fedora sorcery, but
chances are KDE took care of it.
Why not backup your new ~/.kde{,4}, move the old ~/.kde over, start
KDE and see what happens?
--
Oleg Goldshmidt | p...@goldshmidt.org
___
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Just for giveaway and/or trade
Yo, kiddos, I have some computer trash for giveaway or trade. Some misc RAM (SODIMM and RDRAM), a 100Mbit network card, an AGP VGA card or two, some cables. You want it, you come and get it. If you are nice, I want one and one thing only in trade - a vacuum handle for computer room tiles. One. C'est touts. I am not keeping anything for anybody nor carrying anything anywhere. You want it, you come and take from where I live - Mazkeret Batya. Marc Marc Volovic marc.volo...@swiftouch.com ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Problems of a desktop Linux distribution GUI sudo
On Tue, Jun 15, 2010 at 03:02:28AM -0700, Elazar Leibovich wrote: On Tue, Jun 15, 2010 at 12:44 AM, Oron Peled o...@actcom.co.il wrote: 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. I apologize, but at least it's much better than doing the opposite... 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). 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. 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. What's the problem with that? The code size is not an issue. It's not much more than parted itself (it can use libparted). It does not have to run all the time: you may ask dbus to start it only when someone actually asks for it. 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 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 We're indeed talking about different threat models. 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. Nope. It applies equally well for a desktop system. Same mechanism, different policy. I'm (and if I understand correctly, Microsoft also considers this model) talking about securing a desktop user which owns the computer. He always have full control, if he can touch the keyboard - he's OK. A sanity check. The simplest thing to do would be to run everything as root. The system we want to have should be more secure but only marginally less convinient. 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. 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
Re: gcc-4.5.0 Success Story with Freecell Solver
Hi Diego, On Tuesday 15 Jun 2010 23:06:04 Diego Iastrubni wrote: Shlomi: code svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm mkdir -p llvm/tools/clang svn co http://llvm.org/svn/llvm-project/cfe/trunk llvm/tools/clang mkdir llvm/cmake-build cd llvm/cmake-build ccmake ../ make export CC=$PWD/bin/clang export CXX=$PWD/bin/clang++ /code thanks for the recipe to build clang. Now re-compile your library + test tools. (PS, If you want to fully bootstrap clang instead of just using stage1 here, use this ugly shell script to get a clang built with clang built clang, aka stage 3). Please report how good/bad clang is for your case. Well, after I built clang (which took a while) I was able to compile Freecell Solver using it. The first thing I should note is that the compilation appeared to have been much slower than with gcc. Then I benchmarked the results. The benchmark-using-clang ran at 105.567487955093 seconds instead of 90.6 seconds for gcc-4.5.0 - much worse! I don't rule out that my code has some gccisms which make the clang performance worse, but it still seems that gcc-4.5.0 is the superior compiler. Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ Stop Using MSIE - http://www.shlomifish.org/no-ie/ God considered inflicting XSLT as the tenth plague of Egypt, but then decided against it because he thought it would be too evil. Please reply to list if it's a mailing list post - http://shlom.in/reply . ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
