Re: Problems of a desktop Linux distribution GUI sudo
On Jun 14, 2010, at 8:49 AM, Elazar Leibovich wrote: It can't be that bad, I thought, I can probably only sudo a known program. Alas, in the latest version of Ubuntu the sudoers file says %admin ALL=(ALL) ALL At least it still requires you to enter a password. This prevents a random person walking up to your computer and deleting or installing software, etc. If you don't like it you are welcome to create an adminstrator account, change root so that you can log in to it, and comment out (or delete) that line. What doing any of them breaks, I have no idea and accept no responsability for anything breaking. In Windows when you're asked to leverage a permission of a program, it shows you the digital signature of the executable asking for privileges (or at least that's how it looks like in the dialog), which is not a very good solution IMHO, but it's at least better than nothing. That started as an add-on to Windows XP, Windows Defender which originally was Giant Anti-Spyware. Not surprisingly, although it really worked, was not a pain to have on your system, and was free (as in beer, not FOSS), very few people used it. So it was made an integral part of Windows Vista and was the number one complaint. There were many postings about how to turn it off. :-( Geoff. -- geoffrey mendelson N3OWJ/4X1GM Jerusalem Israel geoffreymendel...@gmail.com I do multitasking. If that bothers you, file a complaint and I will start ignoring it immediately. ___ 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 Mon, Jun 14, 2010 at 9:12 AM, geoffrey mendelson geoffreymendel...@gmail.com wrote: On Jun 14, 2010, at 8:49 AM, Elazar Leibovich wrote: It can't be that bad, I thought, I can probably only sudo a known program. Alas, in the latest version of Ubuntu the sudoers file says %admin ALL=(ALL) ALL At least it still requires you to enter a password. This prevents a random person walking up to your computer and deleting or installing software, etc. If you don't like it you are welcome to create an adminstrator account, change root so that you can log in to it, and comment out (or delete) that line. What doing any of them breaks, I have no idea and accept no responsability for anything breaking. And that's exactly the reason I don't want to change the distribution's workflow. This is not a problem for me, I guess that I can figure out which application is requesting the permission by a quick terminal session, but if I expect to use Ubuntu in home desktop of a non-power user, and if (hopefully) someday linux will gain nontrivial market share, that would be a problem. In Windows when you're asked to leverage a permission of a program, it shows you the digital signature of the executable asking for privileges (or at least that's how it looks like in the dialog), which is not a very good solution IMHO, but it's at least better than nothing. That started as an add-on to Windows XP, Windows Defender which originally was Giant Anti-Spyware. Not surprisingly, although it really worked, was not a pain to have on your system, and was free (as in beer, not FOSS), very few people used it. So it was made an integral part of Windows Vista and was the number one complaint. There were many postings about how to turn it off. :-( That's why I said it's not a very good solution. Moreover, I fear that people will get used to clicking OK when those messages pops, and would ignore entirely what is written in them. Anyone knows what's the approach in OSX? Geoff. -- geoffrey mendelson N3OWJ/4X1GM Jerusalem Israel geoffreymendel...@gmail.com I do multitasking. If that bothers you, file a complaint and I will start ignoring it immediately. ___ 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
2010/6/14 Elazar Leibovich elaz...@gmail.com: Alas, in the latest version of Ubuntu the sudoers file says %admin ALL=(ALL) ALL and the default user is indeed in the admin group. Is that really a problem (I'm probably not the only one who noticed it)? I suppose Ubuntu assumes, probably correctly for its target audience, that it runs on a personal machine with one user, so it is reasonable to add the user to the admin group and generally let him/her administer the system. Therefore, the user can basically do everything. It is not a problem in itself, at first glance. It would become a problem if the user would have admin privileges without any additional effort, authentication, etc., the way it is (was? my education stops at XP) on WIndows. Here users belonging to the admin group will need to invoke sudo and enter a password before doing anything nasty, so it does not look as a problem - at first glance. If it said NOPASSWD it would be dangerous since a malicious program running with the default user privileges could do nasty stuff _quietly_ (I don't know how difficult it is to modify /var/log/secure etc. to remove the trace of mischief, but this is for forensics only, in any case) with sudo then. Without NOPASSWD there is a line of defence that counts on the user to stop and wonder why an innocuous program is asking him/her for password. Since most users, unlike you, won't think twice, it might (should? I guess it depends on the paranoia level in the blood flow) be considered problematic. Is it like that in other distributions? I am more familiar with RH who are server-oriented so they do not assume a single user environment. By default each user is a member of his/her private group (I actually hate that, I find users a good default group), instead of admin group there is the more traditional wheel (I understand why Ubuntu prefer admin for their target audience), and the equivalent stanza for the wheel group (allowing the members to do everything with sudo) is commented out by default in sudoers. -- 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: Problems of a desktop Linux distribution GUI sudo
On Mon, Jun 14, 2010 at 08:49:21AM +0300, Elazar Leibovich wrote: When using my Ubuntu I used to make the following pattern, whenever an update symbol showed up in the taskbar above (in gnome it's the upper panel), I clicked on it, entered my password to sudo up the privileges of the update process, and installed the needed packages to the machine. Then I thought, wait a mintue, this is happening all too often! The only security signature I trust here is the shape of the symbol on the taskbar! A malicious program can immitate the update GUI, and lure me to leverage its permissions very easily. It can't be that bad, I thought, I can probably only sudo a known program. Alas, in the latest version of Ubuntu the sudoers file says %admin ALL=(ALL) ALL and the default user is indeed in the admin group. Is that really a problem (I'm probably not the only one who noticed it)? Is it like that in other distributions? In Windows when you're asked to leverage a permission of a program, it shows you the digital signature of the executable asking for privileges (or at least that's how it looks like in the dialog), which is not a very good solution IMHO, but it's at least better than nothing. If you're not happy with the simplicity of su, look into the extra complexity of the various [A-Z][a-z]+Kit-s. Specifically in this case the combination of ConsoleKit and PackageKit. Pros: easier to define more fine-grained policies. Cons: more points of failure. More difficult to understand[1]. /me just runs aptitude as root from a terminal. [1] See e.g.: http://lwn.net/Articles/362986/ -- 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
Re: gcc-4.5.0 Success Story with Freecell Solver
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. Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ What does Zionism mean? - http://shlom.in/def-zionism 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: Problems of a desktop Linux distribution GUI sudo
I think you're missing the very fundamental problem I was discussing. Sudo is great, having the default user in the admin group, enabling him to sudo everything is even better. But this applies only when working with the CLI. However, when using a GUI system, and administrating your system using the GUI, you're exposing the user to a great threat. When using the CLI no software can ask you for input, therefor if you sudo for anything it is definitely you who did that. It is very hard to trick the user into sudo'ing something he didn't want to. When the user is administrating his system through the GUI, he will sudo a legitimate software by typing his password. It is even worse than that - the legitimate software which needs to be sudo'd will ask (by means of the taskbar) from time to time the user to leverage its permission by typing password. The authentication scheme the user employ in order to recognize who asked for permission is only the visual layout of the application. It is very easy for an attacker to make his software look like the update manager, and ask the user to update his software through the taskbar. If the casual user is used to typing his password every time the update manager asks him to update his system - he'll do that for hostile software which uses the update manager's icon as well. Even experienced users might be tricked, as you're having zero visual clue about the software identity. Sudo here is *not* the problem, it's great. The problem is the authentication scheme the GUI sudo version employs in order to recognize which software asked for permission. In windows the authentication scheme seems to be through signed executables, in current version of Ubuntu the authentication scheme is zero. On Mon, Jun 14, 2010 at 2:13 AM, Tzafrir Cohen tzaf...@cohens.org.ilwrote: On Mon, Jun 14, 2010 at 08:49:21AM +0300, Elazar Leibovich wrote: When using my Ubuntu I used to make the following pattern, whenever an update symbol showed up in the taskbar above (in gnome it's the upper panel), I clicked on it, entered my password to sudo up the privileges of the update process, and installed the needed packages to the machine. Then I thought, wait a mintue, this is happening all too often! The only security signature I trust here is the shape of the symbol on the taskbar! A malicious program can immitate the update GUI, and lure me to leverage its permissions very easily. It can't be that bad, I thought, I can probably only sudo a known program. Alas, in the latest version of Ubuntu the sudoers file says %admin ALL=(ALL) ALL and the default user is indeed in the admin group. Is that really a problem (I'm probably not the only one who noticed it)? Is it like that in other distributions? In Windows when you're asked to leverage a permission of a program, it shows you the digital signature of the executable asking for privileges (or at least that's how it looks like in the dialog), which is not a very good solution IMHO, but it's at least better than nothing. If you're not happy with the simplicity of su, look into the extra complexity of the various [A-Z][a-z]+Kit-s. Specifically in this case the combination of ConsoleKit and PackageKit. Pros: easier to define more fine-grained policies. Cons: more points of failure. More difficult to understand[1]. /me just runs aptitude as root from a terminal. [1] See e.g.: http://lwn.net/Articles/362986/ -- 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
Re: Problems of a desktop Linux distribution GUI sudo
On Monday 14 Jun 2010 12:52:30 Elazar Leibovich wrote: I think you're missing the very fundamental problem I was discussing. Sudo is great, having the default user in the admin group, enabling him to sudo everything is even better. But this applies only when working with the CLI. However, when using a GUI system, and administrating your system using the GUI, you're exposing the user to a great threat. When using the CLI no software can ask you for input, therefor if you sudo for anything it is definitely you who did that. It is very hard to trick the user into sudo'ing something he didn't want to. When the user is administrating his system through the GUI, he will sudo a legitimate software by typing his password. It is even worse than that - the legitimate software which needs to be sudo'd will ask (by means of the taskbar) from time to time the user to leverage its permission by typing password. The authentication scheme the user employ in order to recognize who asked for permission is only the visual layout of the application. It is very easy for an attacker to make his software look like the update manager, and ask the user to update his software through the taskbar. If the casual user is used to typing his password every time the update manager asks him to update his system - he'll do that for hostile software which uses the update manager's icon as well. Even experienced users might be tricked, as you're having zero visual clue about the software identity. That's why you should not install software that you should not trust. There's no escape from it. If you install such software as a normal user, it can easily temper with your local user configuration and end up spying on you or getting your credentials - even as an underprivileged user on UNIX. Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ Why I Love Perl - http://shlom.in/joy-of-perl 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: Problems of a desktop Linux distribution GUI sudo
On Mon, Jun 14, 2010 at 02:52:30AM -0700, Elazar Leibovich wrote: I think you're missing the very fundamental problem I was discussing. Sudo is great, having the default user in the admin group, enabling him to sudo everything is even better. But this applies only when working with the CLI. However, when using a GUI system, and administrating your system using the GUI, you're exposing the user to a great threat. When using the CLI no software can ask you for input, therefor if you sudo for anything it is definitely you who did that. It is very hard to trick the user into sudo'ing something he didn't want to. When the user is administrating his system through the GUI, he will sudo a legitimate software by typing his password. It is even worse than that - the legitimate software which needs to be sudo'd will ask (by means of the taskbar) from time to time the user to leverage its permission by typing password. The authentication scheme the user employ in order to recognize who asked for permission is only the visual layout of the application. It is very easy for an attacker to make his software look like the update manager, and ask the user to update his software through the taskbar. If the casual user is used to typing his password every time the update manager asks him to update his system - he'll do that for hostile software which uses the update manager's icon as well. Even experienced users might be tricked, as you're having zero visual clue about the software identity. Sudo here is *not* the problem, it's great. The problem is the authentication scheme the GUI sudo version employs in order to recognize which software asked for permission. In windows the authentication scheme seems to be through signed executables, in current version of Ubuntu the authentication scheme is zero. Hmm... if a program managed to get in a position it can pop up a prompt, it may also sniff your key-strokes. It may also present you a false certification dialog. If you're used to click through certification dialogs, you'll easily miss that. It may also prompt you to update packages, which is quite legitimate, but then after a minute run 'sudo chmod u+s /bin/bash' , while the sudo credentials are still cached. -- 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
Fwd: [Israel.pm] Next Rehovot.pm meeting: (15th June): Introduction to Perl 6
-- Forwarded Message -- Subject: [Israel.pm] Next Rehovot.pm meeting: (15th June): Introduction to Perl 6 Date: Monday 14 Jun 2010, 14:09:40 From: Gabor Szabo szab...@gmail.com To: Perl in Israel p...@perl.org.il, rehovot...@mail.pm.org, n...@perl.org.il hi all, The next meeting of the Rehovot Perl Mongers will take plaec on 15th June (tomorrow) between 18:00-22:00 in the Weizmann Institute in Rehovot in Room 101 in the Levine Building. See details and map on http://rehovot.pm.org/meetings.html The talk starts at 18:30 Content: Introduction to Perl 6 I've just written and gave this talk 2 days ago at the LinuxTag in Berlin. After a short background and a few words on Perl 5 vs. Perl 6 I'll go over a number of examples that is part of the imminent Rakudo * release. People who bring a notebook and enough network connection will be able helped to install Rakudo on their machine. It is quite easy to install so you could do it ahead of the meeting by following the instructions on http://www.rakudo.org/ regards Gabor ps. Please forward this invitation to friends, enemies and co-workers. ___ Perl mailing list p...@perl.org.il http://mail.perl.org.il/mailman/listinfo/perl - -- - Shlomi Fish http://www.shlomifish.org/ Original Riddles - http://www.shlomifish.org/puzzles/ 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
Preserving Blanks in Parameters to Shell Script
Hi. I want to write a script which will nice ffmpeg whatever parameters it is given - ie: #!/bin/sh nice ffmpeg $* # However, what if I have a file named `file one' I would like to type `myscript -i file\ one output.whatever` I do not want to change what I type - the script needs to be a drop-in replacement for the ffmpeg command. Is there any way to do make the script preserve the backslashed space ? TIA -- The day is short, and the work is great,| Aharon Schkolnik and the laborers are lazy, and the reward | is great, and the Master of the house is| aschkol...@gmail.com impatient. - Ethics Of The Fathers Ch. 2| 054 3344135 ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Preserving Blanks in Parameters to Shell Script
use $@ instead of $* On Mon, Jun 14, 2010 at 3:27 PM, Aharon Schkolnik aschkol...@gmail.comwrote: Hi. I want to write a script which will nice ffmpeg whatever parameters it is given - ie: #!/bin/sh nice ffmpeg $* # However, what if I have a file named `file one' I would like to type `myscript -i file\ one output.whatever` I do not want to change what I type - the script needs to be a drop-in replacement for the ffmpeg command. Is there any way to do make the script preserve the backslashed space ? TIA -- The day is short, and the work is great,| Aharon Schkolnik and the laborers are lazy, and the reward | is great, and the Master of the house is| aschkol...@gmail.com impatient. - Ethics Of The Fathers Ch. 2| 054 3344135 ___ 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
Re: Problems of a desktop Linux distribution GUI sudo
1) I'm not sure sniffing your keyboard and recognizing when you type your password is so easy, but I might be wrong. 2) I believe that there's some mechanism which prevents any other software to mask graphically the authentication dialog, so that if you're seeing the real authentication dialog - you can trust what you see. However using Vista signed executable idea, for instance none of this could happen, since every time a program asks for privilege leverage the dialog box states explicitly which executable is asking for it, and you never write your own password except in login, so whatever the malicious program does it cannot get root privileges. (Please note, I'm aware there are many problems with the current Vista approach, and I don't think at all it's an ideal solution. New ideas must be sought, and I'll be glad to hear any distribution who implemented better approaches. However, as I previously said, it's better than nothing.) On Mon, Jun 14, 2010 at 3:21 AM, Tzafrir Cohen tzaf...@cohens.org.ilwrote: On Mon, Jun 14, 2010 at 02:52:30AM -0700, Elazar Leibovich wrote: I think you're missing the very fundamental problem I was discussing. Sudo is great, having the default user in the admin group, enabling him to sudo everything is even better. But this applies only when working with the CLI. However, when using a GUI system, and administrating your system using the GUI, you're exposing the user to a great threat. When using the CLI no software can ask you for input, therefor if you sudo for anything it is definitely you who did that. It is very hard to trick the user into sudo'ing something he didn't want to. When the user is administrating his system through the GUI, he will sudo a legitimate software by typing his password. It is even worse than that - the legitimate software which needs to be sudo'd will ask (by means of the taskbar) from time to time the user to leverage its permission by typing password. The authentication scheme the user employ in order to recognize who asked for permission is only the visual layout of the application. It is very easy for an attacker to make his software look like the update manager, and ask the user to update his software through the taskbar. If the casual user is used to typing his password every time the update manager asks him to update his system - he'll do that for hostile software which uses the update manager's icon as well. Even experienced users might be tricked, as you're having zero visual clue about the software identity. Sudo here is *not* the problem, it's great. The problem is the authentication scheme the GUI sudo version employs in order to recognize which software asked for permission. In windows the authentication scheme seems to be through signed executables, in current version of Ubuntu the authentication scheme is zero. Hmm... if a program managed to get in a position it can pop up a prompt, it may also sniff your key-strokes. It may also present you a false certification dialog. If you're used to click through certification dialogs, you'll easily miss that. It may also prompt you to update packages, which is quite legitimate, but then after a minute run 'sudo chmod u+s /bin/bash' , while the sudo credentials are still cached. -- 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
Re: Preserving Blanks in Parameters to Shell Script
On Monday, June 14, 2010, Noam Meltzer wrote: use $@ instead of $* Does that work for you ? I still get the same results - the script treates file\ one as two parameters - file and one. On Mon, Jun 14, 2010 at 3:27 PM, Aharon Schkolnik aschkol...@gmail.comwrote: Hi. I want to write a script which will nice ffmpeg whatever parameters it is given - ie: #!/bin/sh nice ffmpeg $* # However, what if I have a file named `file one' I would like to type `myscript -i file\ one output.whatever` I do not want to change what I type - the script needs to be a drop-in replacement for the ffmpeg command. Is there any way to do make the script preserve the backslashed space ? TIA -- The day is short, and the work is great,| Aharon Schkolnik and the laborers are lazy, and the reward | is great, and the Master of the house is| aschkol...@gmail.com impatient. - Ethics Of The Fathers Ch. 2| 054 3344135 ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Preserving Blanks in Parameters to Shell Script
On 14 June 2010 22:48, Aharon Schkolnik aschkol...@gmail.com wrote: On Monday, June 14, 2010, Noam Meltzer wrote: use $@ instead of $* Does that work for you ? I still get the same results - the script treates file\ one as two parameters - file and one. 1. Try switching to #!/bin/bash - I think the $@ is a bash-specific extension which might be disabled if bash is called as sh. 2. Add double-quotes around the $@, (ie. make it read 'nice ffmpege $@' without the single-quotes) BTW - if the nice ffmpeg is the last line in the script then you can add an exec in front of it. --Amos ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Preserving Blanks in Parameters to Shell Script
I'm sorry. I tend to forget why I hate shell scripts. Use $@ instead. (checked it this time, it works ;-) ) 2010/6/14 Aharon Schkolnik aschkol...@gmail.com On Monday, June 14, 2010, Noam Meltzer wrote: use $@ instead of $* Does that work for you ? I still get the same results - the script treates file\ one as two parameters - file and one. On Mon, Jun 14, 2010 at 3:27 PM, Aharon Schkolnik aschkol...@gmail.comwrote: Hi. I want to write a script which will nice ffmpeg whatever parameters it is given - ie: #!/bin/sh nice ffmpeg $* # However, what if I have a file named `file one' I would like to type `myscript -i file\ one output.whatever` I do not want to change what I type - the script needs to be a drop-in replacement for the ffmpeg command. Is there any way to do make the script preserve the backslashed space ? TIA -- The day is short, and the work is great,| Aharon Schkolnik and the laborers are lazy, and the reward | is great, and the Master of the house is| aschkol...@gmail.com impatient. - Ethics Of The Fathers Ch. 2| 054 3344135 ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Preserving Blanks in Parameters to Shell Script
On Monday, June 14, 2010, Noam Meltzer wrote: I'm sorry. I tend to forget why I hate shell scripts. Use $@ instead. (checked it this time, it works ;-) ) Yep - looks like nice ffmpeg $@ does the trick. Thanks ! 2010/6/14 Aharon Schkolnik aschkol...@gmail.com On Monday, June 14, 2010, Noam Meltzer wrote: use $@ instead of $* Does that work for you ? I still get the same results - the script treates file\ one as two parameters - file and one. On Mon, Jun 14, 2010 at 3:27 PM, Aharon Schkolnik aschkol...@gmail.comwrote: Hi. I want to write a script which will nice ffmpeg whatever parameters it is given - ie: #!/bin/sh nice ffmpeg $* # However, what if I have a file named `file one' I would like to type `myscript -i file\ one output.whatever` I do not want to change what I type - the script needs to be a drop-in replacement for the ffmpeg command. Is there any way to do make the script preserve the backslashed space ? TIA -- The day is short, and the work is great,| Aharon Schkolnik and the laborers are lazy, and the reward | is great, and the Master of the house is| aschkol...@gmail.com impatient. - Ethics Of The Fathers Ch. 2| 054 3344135 ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Preserving Blanks in Parameters to Shell Script
Quoting Noam Meltzer tsn...@gmail.com: use $@ instead of $* But put it in quotes: $@. Otherwise the effect is lost. Herouth ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Preserving Blanks in Parameters to Shell Script
On Monday 14 Jun 2010 15:27:43 Aharon Schkolnik wrote: Hi. I want to write a script which will nice ffmpeg whatever parameters it is given - ie: #!/bin/sh nice ffmpeg $* # However, what if I have a file named `file one' I would like to type `myscript -i file\ one output.whatever` I do not want to change what I type - the script needs to be a drop-in replacement for the ffmpeg command. Is there any way to do make the script preserve the backslashed space ? Yes, use quotes: [shell] # Untested #!/bin/sh nice ffmpeg $@ [/shell] $@ when in quotes causes it to be something like $1 $2 $3 $4 , and so forth up to the number of quotes. The whitespace-in-shell-variables-handling is part of a general code/markup injection problem: * http://community.livejournal.com/shlomif_tech/35301.html * http://community.livejournal.com/shlomif_tech/14671.html Regards, Shlomi Fish -- - Shlomi Fish http://www.shlomifish.org/ My Aphorisms - http://www.shlomifish.org/humour.html 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: Problems of a desktop Linux distribution GUI sudo
On Mon, Jun 14, 2010 at 05:36:33AM -0700, Elazar Leibovich wrote: 1) I'm not sure sniffing your keyboard and recognizing when you type your password is so easy, but I might be wrong. 2) I believe that there's some mechanism which prevents any other software to mask graphically the authentication dialog, so that if you're seeing the real authentication dialog - you can trust what you see. It's not about masking one. It's about faking one. However using Vista signed executable idea, for instance none of this could happen, since every time a program asks for privilege leverage the dialog box states explicitly which executable is asking for it, and you never write your own password except in login, so whatever the malicious program does it cannot get root privileges. Never is a very strong word. The main problem here is that you'll eventually need to run untrusted binaries for varius reasons. And thus you'll get used to bypassing that mechnism on a regular basis. Not to mention that trusted binaries may do way to much. For instance, /bin/bash is a trusted binary on your Linux system. It is instealled from a signed package. Yet chmod s+u /bin/bash is not such a grand idea. Trusting any signed binaries sounds all too much like a generic sudo line. It might be a good solution, but not for this problem. Again, look into the *Kit stuff, if sudo is not good enough for you. -- 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
Re: Preserving Blanks in Parameters to Shell Script
On Mon, Jun 14, 2010 at 11:02:11PM +1000, Amos Shapira wrote: On 14 June 2010 22:48, Aharon Schkolnik aschkol...@gmail.com wrote: On Monday, June 14, 2010, Noam Meltzer wrote: use $@ instead of $* Does that work for you ? I still get the same results - the script treates file\ one as two parameters - file and one. 1. Try switching to #!/bin/bash - I think the $@ is a bash-specific extension which might be disabled if bash is called as sh. It's not bash specific. Mind you, on some systems /bin/sh may point to something other than bash. -- 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
Re: Problems of a desktop Linux distribution GUI sudo
On Mon, Jun 14, 2010 at 4:54 PM, Tzafrir Cohen tzaf...@cohens.org.ilwrote: On Mon, Jun 14, 2010 at 05:36:33AM -0700, Elazar Leibovich wrote: 1) I'm not sure sniffing your keyboard and recognizing when you type your password is so easy, but I might be wrong. 2) I believe that there's some mechanism which prevents any other software to mask graphically the authentication dialog, so that if you're seeing the real authentication dialog - you can trust what you see. It's not about masking one. It's about faking one. I don't understand, what would faking a dialog give the attacker? (If you're saying that it will cause the user to ignore permission dialogs altogether, I don't think it's plausible, on the contrary, the user will notice something is suspicious - the package update software is asking for update, yet, nothing happens. However using Vista signed executable idea, for instance none of this could happen, since every time a program asks for privilege leverage the dialog box states explicitly which executable is asking for it, and you never write your own password except in login, so whatever the malicious program does it cannot get root privileges. Never is a very strong word. The main problem here is that you'll eventually need to run untrusted binaries for varius reasons. And thus you'll get used to bypassing that mechnism on a regular basis. Not to mention that trusted binaries may do way to much. For instance, /bin/bash is a trusted binary on your Linux system. It is instealled from a signed package. Yet chmod s+u /bin/bash is not such a grand idea. In the authentication dialog you will see the command line which is requested, and if it's something like /bin/bash rm -rf / ignore it. Moreover I wouldn't allow bash to ask for permission leverage through the GUI at all. Trusting any signed binaries sounds all too much like a generic sudo line. It might be a good solution, but not for this problem. Again, look into the *Kit stuff, if sudo is not good enough for you. Again, sudo is super. 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. -- 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
Re: Problems of a desktop Linux distribution GUI sudo
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 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. -- 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
Re: Problems of a desktop Linux distribution GUI sudo
On Mon, Jun 14, 2010 at 6:04 PM, Tzafrir Cohen tzaf...@cohens.org.ilwrote: 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. -- 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
Re: Problems of a desktop Linux distribution GUI sudo
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.ilwrote: 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
Re: Problems of a desktop Linux distribution GUI sudo
The problem: In the current workflow for desktop linux, you need to routinely leverage the privilege of some GUI application. Those applications runs constantly in the background and might prompt the user to take action. We *want *those application to constantly run in the background and prompt the user to take action. This is a good thing. When the program asks the user to leverage its privileges, the standard leverage dialog does not contain any verifiable information for who actually asked to leverage its permissions. That is, the only authentication method the user employ to verify he's giving root privilege to the correct program are this program's visual look. However, this workflow enables a simple attack. The offending program would change its look to look like a legitimate program, and ask the user to leverage its permissions. The user has no way to know that he's leveraging the permissions of a different program. This program can be solved in many ways, for instance: 1) Allow the user to sudo only a limited set of software. 2) Allow the user to sudo all programs, but do not allow any software to prompt the user for extra permission. But I'm not interested with extra limitations. I want to allow the user sudo'ing whatever he wishes, to allow any program to prompt for extra permissions, but still disallow a malicious software to disguise as a legitimate software, and trick the user to give it extra privileges. 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. 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!). 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. On Mon, Jun 14, 2010 at 6:55 PM, Tzafrir Cohen tzaf...@cohens.org.ilwrote: 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
Re: Problems of a desktop Linux distribution GUI sudo
On Mon, Jun 14, 2010 at 08:12:43PM +0300, Elazar Leibovich wrote: The problem: In the current workflow for desktop linux, you need to routinely leverage the privilege of some GUI application. Those applications runs constantly in the background and might prompt the user to take action. We *want *those application to constantly run in the background and prompt the user to take action. This is a good thing. When the program asks the user to leverage its privileges, the standard leverage dialog does not contain any verifiable information for who actually asked to leverage its permissions. That is, the only authentication method the user employ to verify he's giving root privilege to the correct program are this program's visual look. However, this workflow enables a simple attack. The offending program would change its look to look like a legitimate program, and ask the user to leverage its permissions. The user has no way to know that he's leveraging the permissions of a different program. This program can be solved in many ways, for instance: 1) Allow the user to sudo only a limited set of software. 2) Allow the user to sudo all programs, but do not allow any software to prompt the user for extra permission. But I'm not interested with extra limitations. I want to allow the user sudo'ing whatever he wishes, to allow any program to prompt for extra permissions, but still disallow a malicious software to disguise as a legitimate software, and trick the user to give it extra privileges. Define malicious software. For instance, should a script that I wrote be considered malicious? A script that root wrote? 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. 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!). 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. A certificate may serve to guarantee that the software indeed comes from a well-known vendor. But it says nothing about it being safe for running under sudo. Do I want to allow my users to run all the Sun programs? (and by extension: all Java programs, through a JVM) with root privs? This is a good(?) answer to a different question. -- 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
Re: Problems of a desktop Linux distribution GUI sudo
On 14/06/2010 19:12, Elazar Leibovich wrote: The problem: In the current workflow for desktop linux, you need to routinely leverage the privilege of some GUI application. Those applications runs constantly in the background and might prompt the user to take action. We *want *those application to constantly run in the background and prompt the user to take action. This is a good thing. When the program asks the user to leverage its privileges, the standard leverage dialog does not contain any verifiable information for who actually asked to leverage its permissions. That is, the only authentication method the user employ to verify he's giving root privilege to the correct program are this program's visual look. However, this workflow enables a simple attack. The offending program would change its look to look like a legitimate program, and ask the user to leverage its permissions. The user has no way to know that he's leveraging the permissions of a different program. This program can be solved in many ways, for instance: 1) Allow the user to sudo only a limited set of software. 2) Allow the user to sudo all programs, but do not allow any software to prompt the user for extra permission. But I'm not interested with extra limitations. I want to allow the user sudo'ing whatever he wishes, to allow any program to prompt for extra permissions, but still disallow a malicious software to disguise as a legitimate software, and trick the user to give it extra privileges. 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. 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!). 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. On Mon, Jun 14, 2010 at 6:55 PM, Tzafrir Cohen tzaf...@cohens.org.il mailto: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 mailto:tzaf...@cohens.org.ilwrote: 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 mailto:tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il mailto:tzaf...@cohens.org.il | | best tzaf...@debian.org mailto:tzaf...@debian.org| | friend E.G. Run rkhunter as a startup procedure or wrap sudo in a script that checks -- Moish ___ 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 Mon, Jun 14, 2010 at 8:41 PM, Tzafrir Cohen tzaf...@cohens.org.ilwrote: On Mon, Jun 14, 2010 at 08:12:43PM +0300, Elazar Leibovich wrote: [snip] But I'm not interested with extra limitations. I want to allow the user sudo'ing whatever he wishes, to allow any program to prompt for extra permissions, but still disallow a malicious software to disguise as a legitimate software, and trick the user to give it extra privileges. Define malicious software. For instance, should a script that I wrote be considered malicious? A script that root wrote? Depends on the user. He will decide if your script should get root privileges. If I were him I'll never give root privileges to anything which is not an installer. But what shouldn't happen is that *his *script will disguise as your script, and will ask for root permissions. I will then give *his* script permission because I trust your script, this is the heart of the problem and this is wrong. 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. 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!). 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. A certificate may serve to guarantee that the software indeed comes from a well-known vendor. But it says nothing about it being safe for running under sudo. Do I want to allow my users to run all the Sun programs? (and by extension: all Java programs, through a JVM) with root privs? Hold it a bit, most software won't need to run as root, so usually the answer is no. It is legitimate to require scripts that are supposed to run as root to be compiled to a signed executable that would be signed. (It is a good idea in general BTW, for instance gnome-do fails to recognize java programs which are ran by bash script). BTW you don't have to sign the executables by crypto. It is enough to show the full path of the software, and warn the user if he has write permission to the place where the executable resides. But even for scripts it improves the system security. Since you would see exactly which command line is about to run, and you would be able to decide if you are being tricked or not. (It is much more unlikely that a malicious software will follow your keystroke an would switch the script you're just about to sudo). The bottom line is, that I feel 100% safe to click OK on my Java update sudo in Vista, but I feel scared to do the same for the update manager on Ubuntu. While its not the ideal solution, I believe it gives a good MAANE This is a good(?) answer to a different question. -- 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
Re: Problems of a desktop Linux distribution GUI sudo
On Mon, Jun 14, 2010 at 09:22:23PM +0300, Elazar Leibovich wrote:
On Mon, Jun 14, 2010 at 8:41 PM, Tzafrir Cohen tzaf...@cohens.org.ilwrote:
On Mon, Jun 14, 2010 at 08:12:43PM +0300, Elazar Leibovich wrote:
[snip]
But I'm not interested with extra limitations. I want to allow the user
sudo'ing whatever he wishes, to allow any program to prompt for extra
permissions, but still disallow a malicious software to disguise as a
legitimate software, and trick the user to give it extra privileges.
Define malicious software.
For instance, should a script that I wrote be considered malicious? A
script that root wrote?
Depends on the user. He will decide if your script should get root
privileges. If I were him I'll never give root privileges to anything which
is not an installer.
But what shouldn't happen is that *his *script will disguise as your script,
and will ask for root permissions. I will then give *his* script permission
because I trust your script, this is the heart of the problem and this is
wrong.
So you need to grant local {user?|admin?} the permission to sign
executables?
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.
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!).
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.
A certificate may serve to guarantee that the software indeed comes from
a well-known vendor. But it says nothing about it being safe for running
under sudo.
Do I want to allow my users to run all the Sun programs? (and by
extension: all Java programs, through a JVM) with root privs?
Hold it a bit, most software won't need to run as root, so usually the
answer is no. It is legitimate to require scripts that are supposed to run
as root to be compiled to a signed executable that would be signed. (It is a
good idea in general BTW, for instance gnome-do fails to recognize java
programs which are ran by bash script).
BTW you don't have to sign the executables by crypto. It is enough to show
the full path of the software, and warn the user if he has write permission
to the place where the executable resides.
So now we don't assume user is completely clueless, and we basically
drop the whole signing idea.
Full command-line sounds saner. gksudo alsready does that here.
But even for scripts it improves the system security. Since you would see
exactly which command line is about to run, and you would be able to decide
if you are being tricked or not. (It is much more unlikely that a malicious
software will follow your keystroke an would switch the script you're just
about to sudo).
The bottom line is, that I feel 100% safe to click OK on my Java update sudo
in Vista, but I feel scared to do the same for the update manager on Ubuntu.
While its not the ideal solution, I believe it gives a good MAANE
--
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
Re: Problems of a desktop Linux distribution GUI sudo
I don't understand.
An executable can be signed or unsigned. Anyone can sign it, but the name of
the signee would appear on it.
If I see your script with your name on it, I can decide whether or not to
execute it.
What cannot happen in that case that I'll think your script is the update
manager, since the executable is signed (as I mentioned signature can be
implemented using, say, executable path and not only with crypto).
The user has a variable amount of clue, but it doesn't matter.
Even an experienced user (like yourself) won't be able to differentiate a
script claiming he's the update manager from the real update manager. This
is solved. Because it's theoretically impossible, the input on the screen is
identical in both cases.
We never drop the executable signing idea, which has no relation whatsoever
to the question whether or not the user has clue.
On Mon, Jun 14, 2010 at 10:21 PM, Tzafrir Cohen tzaf...@cohens.org.ilwrote:
On Mon, Jun 14, 2010 at 09:22:23PM +0300, Elazar Leibovich wrote:
On Mon, Jun 14, 2010 at 8:41 PM, Tzafrir Cohen tzaf...@cohens.org.il
wrote:
On Mon, Jun 14, 2010 at 08:12:43PM +0300, Elazar Leibovich wrote:
[snip]
But I'm not interested with extra limitations. I want to allow the
user
sudo'ing whatever he wishes, to allow any program to prompt for extra
permissions, but still disallow a malicious software to disguise as a
legitimate software, and trick the user to give it extra privileges.
Define malicious software.
For instance, should a script that I wrote be considered malicious? A
script that root wrote?
Depends on the user. He will decide if your script should get root
privileges. If I were him I'll never give root privileges to anything
which
is not an installer.
But what shouldn't happen is that *his *script will disguise as your
script,
and will ask for root permissions. I will then give *his* script
permission
because I trust your script, this is the heart of the problem and this is
wrong.
So you need to grant local {user?|admin?} the permission to sign
executables?
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.
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!).
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.
A certificate may serve to guarantee that the software indeed comes
from
a well-known vendor. But it says nothing about it being safe for
running
under sudo.
Do I want to allow my users to run all the Sun programs? (and by
extension: all Java programs, through a JVM) with root privs?
Hold it a bit, most software won't need to run as root, so usually the
answer is no. It is legitimate to require scripts that are supposed to
run
as root to be compiled to a signed executable that would be signed. (It
is a
good idea in general BTW, for instance gnome-do fails to recognize java
programs which are ran by bash script).
BTW you don't have to sign the executables by crypto. It is enough to
show
the full path of the software, and warn the user if he has write
permission
to the place where the executable resides.
So now we don't assume user is completely clueless, and we basically
drop the whole signing idea.
Full command-line sounds saner. gksudo alsready does that here.
But even for scripts it improves the system security. Since you would see
exactly which command line is about to run, and you would be able to
decide
if you are being tricked or not. (It is much more unlikely that a
malicious
software will follow your keystroke an would switch the script you're
just
about to sudo).
The bottom line is, that I feel 100% safe to click OK on my Java update
sudo
in Vista, but I feel scared to do the same for the update manager on
Ubuntu.
While its not the ideal solution, I believe it gives a good MAANE
--
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
Re: Problems of a desktop Linux distribution GUI sudo
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 gsomething_I_forgotsu, 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
