Re: Debian patching KDE to use /etc for configuration (was: Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names)
> > > > How about uncommenting a line that does so. All you are buying into is > > a default setup. > > App authors don't ship configs like that though. Does apt ship a sudo > config? Does anything? Perhaps you missed my opening message on this topic, except it was in your first reply. __ I remember reading a while back that distros had some blunders in writing secure sudoers files and so it was emptied. Is that true? I still ascert that apps adding groups with NOPASSWD sudoers lines perhaps even commented out by default in all or some cases is far better than polkit for many reasons. Any counter argument can apply to sudo too and rather easily. > The nice thing about (really dbus, not so much polkit per se) is that > I can offer a nice API for applications that is not command line > based. No parsing strings, no 'oh this tool writes to stderr, that one > writes to stdout, I need to ignore these lines...) > What is wrong with sed and you can simply echo files in some sudoers.d config. What kind of unix dev cannot handle text strings. That is one of the problems with it too, especially if polkit becomes over used and perhaps this is below the belt but it's certainly true that IPC has caused Android more than enough security issues. > > > >> I don't understand 'the APIs that coders will learn instead of C.' Can > >> you elaborate? Polkit has a C api... > >> > > > > It has an api that is simply not needed? Small tools are better. > > You prefer the commandline api? (one byte for return values, half of > which are signals) > What's the problem there?. I have already stated some of the very important benefits. > > > >> I don't understand how the code will 'not be well designed to the > >> application at hand.' I mean ideally the API and the CLI are > >> essentially just wrappers around the same library of functions. > >> > > > > If you search for sites that evaluate polkit you will see that it is > > considered to encourage granting more permissions than necessary rather > > than coding a specific tool. > > Hah, because no one uses sudo to grant extraordinarily broad permissions. > They do, but it encourages them not to and not vice versa and they can easily customise the default rule to say emerge -moresecurethandefault Win Win and a couple more Wins in fact > > > >> Its unclear how polkit is 'hard'. Now it *is* new, and I will concede > >> you will have to read some manpages. However i don't think the > >> concepts are difficult. > > > > Man pages won't help with polkit and it actually generally ships with no > > configs by default. > > In Ubuntu Precise.. You still have to do way more than commenting or editing a file to restrict the default further, aka it's unlikely to happen. > > All of this is explained in man polkit. > And pkauthority and and How will that help when as I have mentioned a coders comments aren't even sure exactly what the code permits. > > > > I know about pkaction, the problem is that the actions tells you next to > > nothing about what is actually allowed. I haven't time to dig out one > > of the rediculous comments from the source now unfortunately. With > > small tools it's much better all round. > > Really? Please enumerate what giving someone access to 'emerge' can do. > Exactly, you see man emerge and grepping the source does work perfectly well there. You could make myemerge pretty quick too. > > No one maintains the sudo wrappers though. Someone maintains the > polkit actions. That someone also happens to be the upstream author. > That's what I am asking, is there any reason not to as it would be better? No reason has come up yet? > > > >> Is the polkit maintain any less 'trustworthy' than the gnome > >> maintainers? the kde maintainers? the kernel maintainers? At the end > >> of the day my machines are running software from thousands of > >> contributors. > >> > > > > I think that has been demonstrated and we are talking about root code > > and sudo is never running as such. > > I don't follow... > It is certainly far easier to exploit polkit than sudo with a decent sudoers of course for multiple reasons. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: Debian patching KDE to use /etc for configuration (was: Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names)
> > > > I never meant it is rubbish as such but I saw it as rediculously > > inferior to sudo before I even read this. > > > > http://drfav.wordpress.com/2012/05/11/the-quest-towards-trusted-client-applications-a-rambling/ > > Perhaps I'm misunderstanding, but that is talking about a specific set > of problems that I don't think polkit was actually designed to > address. Polkit is basically for authenticating applications via > users, not the applications themselves. If I am running app foo, and > app foo wants to inhibit hibernation; polkit is there to ask 'hey is > antarus allowed to inhibit hibernation? Does antarus need to auth to > do so? Is antarus already authenticated? Now one may say 'hey but I > only want certain applications to hibernate' and while that may be an > interesting problem...I don't think the existing polkit intends to > solve it. > The point is that it is inferior in every way and so pointlessly causing more work and other problems not to mention guaranteed increased security risk having extra code constantly running as root. Why was it started, rather than contributing to sudo. > > > > > >> It is however, designed for graphical UI single-seat systems. > >> Its command line support sucks (they only added a CLI auth agent in > >> May) and it is not well adopted. Multi-user systems do not work well > >> with polkit. Certainly with polkit and dbus you can allow users to > >> take more specific action without complex wrappers, setuid scripts, or > >> sudo. > > > > Except you can't, it only encourages more coarse grained approaches, > > less useful commands available and devs to learn an api rather than C > > and simply moves code into a far less secure mechanism and increases the > > chance that the code will not be well designed to the task at hand and > > running as root. It can be a real pain to work out exactly what polkit > > allows and you cannot just edit it to suit your application and it > > completely ignores the existing unix security technologies with > > brilliant track records. > > One could say that 'a discrete set of APIs will be no match for > the..fined grain control that is the command line!' I would agree. I > don't agree that this is a one-size fits all deal though. There can be > a command line AND an API. I'd rather grant my users 'access to the > install authenticated packages action' than have to own a complex sudo > rule. > How about uncommenting a line that does so. All you are buying into is a default setup. > I don't understand 'the APIs that coders will learn instead of C.' Can > you elaborate? Polkit has a C api... > It has an api that is simply not needed? Small tools are better. > I don't understand how the code will 'not be well designed to the > application at hand.' I mean ideally the API and the CLI are > essentially just wrappers around the same library of functions. > If you search for sites that evaluate polkit you will see that it is considered to encourage granting more permissions than necessary rather than coding a specific tool. > Its unclear how polkit is 'hard'. Now it *is* new, and I will concede > you will have to read some manpages. However i don't think the > concepts are difficult. Man pages won't help with polkit and it actually generally ships with no configs by default. > There are plenty of helpers (pkcheck springs > to mind) that assist the user in figuring out what is 'allowed'. I know about pkaction, the problem is that the actions tells you next to nothing about what is actually allowed. I haven't time to dig out one of the rediculous comments from the source now unfortunately. With small tools it's much better all round. >The > configuration for polkit is all in /usr/share and /etc. The configs > are configurable..again in /etc. This is not something I would term > 'challenging.' > Generally there aren't any rules files, the defaults are built in and your expected to use a webbrowser, even on a server?!?! You shouldn't run lynx never mind X on a server. If some configs are in /usr/share rather than /etc perhaps that explains why one tutorial said so and it has no effect on some systems. > > > > You could try to argue that many eyes will look at a central piece of > > code but in fact less implementations will likely mean less eyes and > > just assumption that a guy who got JS through as a config language has > > everything covered. Granted, unmaintained code running as root may be > > higher with sudo but if it needs maintaining, should it be running as > > root at all or is it actually simply doing too much. > > Its not a matter of many-eyes. It is a matter of 'some other guy is in > charge of maintaining that component.' It means I can focus on stuff > that matters, and not focus on 'wrappers to make random things work.' That can apply to sudo, would be more secure and cause less problems and you see why I brought it up and asked why not, because that should be the case. > Is the polkit maintain an
Re: Debian patching KDE to use /etc for configuration (was: Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names)
On Tue, 15 Jan 2013 22:19:37 +0200 Maxim Kammerer wrote: > This is a major problem, there are other questionable choices that > raise the question whether developers are familiar with how things are > done on Unix: > https://bugs.freedesktop.org/show_bug.cgi?id=58787 > I have to confess that despite this being a serious matter that really made me chuckle. > > Sudo even supports regex! > > Only glob patterns, and it's not too good at that. > http://www.sudo.ws/bugs/show_bug.cgi?id=500 /etc/sudoers: anonliberte = NOPASSWD: /sbin/shutdown -[hr] now sudo shutdown -h now -> allowed sudo shutdown "-h now" -> allowed (probably shouldn't be) It may not be perfect and is why I would love to see distros grow some balls or perhaps more rightly packagers and embrace sudoers again but it is far clearer what is allowed than polkit and I believe. /sbin/shutdown -[h][r] Would do what you want. You may need to test but I have never found a command I couldn't add to sudoers. After all it can only make the likes of Ubuntu and perhaps all in fact more secure ;-)
Re: Debian patching KDE to use /etc for configuration (was: Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names)
> > Unless sudo has some config setting that allows access only when > > logged in via console it isn't really a solution. > > > > Rich > > man sudoers -> /requiretty > > I manage 'thousands' of desktops at Google and we generally like > polkit. I never meant it is rubbish as such but I saw it as rediculously inferior to sudo before I even read this. http://drfav.wordpress.com/2012/05/11/the-quest-towards-trusted-client-applications-a-rambling/ > It is however, designed for graphical UI single-seat systems. > Its command line support sucks (they only added a CLI auth agent in > May) and it is not well adopted. Multi-user systems do not work well > with polkit. Certainly with polkit and dbus you can allow users to > take more specific action without complex wrappers, setuid scripts, or > sudo. Except you can't, it only encourages more coarse grained approaches, less useful commands available and devs to learn an api rather than C and simply moves code into a far less secure mechanism and increases the chance that the code will not be well designed to the task at hand and running as root. It can be a real pain to work out exactly what polkit allows and you cannot just edit it to suit your application and it completely ignores the existing unix security technologies with brilliant track records. You could try to argue that many eyes will look at a central piece of code but in fact less implementations will likely mean less eyes and just assumption that a guy who got JS through as a config language has everything covered. Granted, unmaintained code running as root may be higher with sudo but if it needs maintaining, should it be running as root at all or is it actually simply doing too much. > My package manager can have a polkit action like 'install a > signed package' and I can grant the user access to do that, but not > access to install unsigned packages (root exploit there...) or run > other dangerous apt commands. It comes built into apt, so I don't have > to write extra wrappers. That would be the default and wouldn't even need the command line argument control of sudo. Just allowing updates is apt-get update. In fact I have a debian system where experimental iceweasel is installable but nothing else. I have an Arch system where the only kernel updateable is a signed by me when offline kernel and polkit is disabled as I don't have the time to keep track of what it is permitting and code comments weren't helpful there. Sudo even supports regex! p.s. apt should be downloading as an _apt user, simply as best practice before adding polkit support ;-) -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: Debian patching KDE to use /etc for configuration (was: Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names)
> > Debian having to patch KDE to use /etc for configs is simply wrong too. > > huh huh, do you know if they have a fix for > http://bugs.gentoo.org/438790 to stop KDE from destroying upstream > polkit files? I don't, I just know that on Debian the configs are in /etc and the bug you mention, comments was what caused me to comment. "Debian patches to make /etc/kde4 the config directory". Of course it may just be that debians KDE hasn't got the polkit rubbish as it is older. I remember reading a while back that distros had some blunders in writing secure sudoers files and so it was emptied. Is that true? I still ascert that apps adding groups with NOPASSWD sudoers lines perhaps even commented out by default in all or some cases is far better than polkit for many reasons. Any counter argument can apply to sudo too and rather easily. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [gentoo-dev] Re: Re: call for testers: udev predictable network interface names
> William is packaging upstream udev for Gentoo. > > You are shooting the messenger. I expect there is 0 blame meant for William. P.s. Is it William that Lennart dished some blame in the direction of. I completely disagree. It's not the job of every distro to look for all build flags to fix some software's defaults because other software has some small issues. That's simply ludicrous and my best guess is it being a feeble attempt at reasoning an excuse. At the very least and like in many release notes, it should have been made clear that distros may wish to consider using that flag to keep the current behaviour whether any reason to do was understood or not. The thought strikes me now that in the reverse case their likely wouldn't be any justification for having a build flag? Debian having to patch KDE to use /etc for configs is simply wrong too. You are right though, I don't suppose it helps much airing any of it here. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [gentoo-dev] Re: call for testers: udev predictable network interface names
> but > again it appears that simple cases are being made complex, just to allow > for someone else's complex cases. Which is faulty logic. It's a welcome option but an important question seems to be; Why wasn't this picked up in the dev cycle?. This reminds me of udisks 8 months ago losing features for multi-seat costing me time to replace it with udev and scripts which I still prefer. Is it coincidence that Redhat wanted complex multiseat at all costs for udisks and Redhat want fast boot at all cost for cloud services? p.s. I am very glad of RedHats contributions and respect their position of giving coders freedom but I just think that if they are able to fund coders to look after a corner full-time or completely then they need to manage that corner or atleast have some ground rules to cover any case of my way or the high way. The kernel wouldn't tolerate this kind of breakage and I really hope I never see linux userland as dependent on IPC as minix is or as broken without IPC as windows is without RPC. I take the unarguably more secure well setup sudoers and useful small tools anyone can use or take code from over polkit anyday. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [gentoo-dev] Gentoo and Root CAs
On Mon, 31 Dec 2012 15:42:39 +0100 Tobias Klausmann wrote: > I _do_ think that his concerns need > to be addressed, particularly the second half of his statement. Whilst I agree that if it does debians system shouldn't undermine mozillas. I think the latest efforts are a pointless bandaid but I'm sure better solutions should come if we can get around the CAs wanting to make money issue. "Can you prove you know what certificates were issued, to whom, and who authorized them?" Accountability 101! It's not perfect, but it's a huge step forward from "Oh, this guy I know says its cool" Is it really. Introducing trust on people we don't know and can't possibly verify (yes I know the procedures that you could argue badly are better than none). What SSL protects is data between two servers and all that is required is to ensure that you are talking securely to the server or domain name you have chosen trust. Anything else is simply adding vectors of attack and false senses of security. I thought DNSSEC maybe extremely useful for ssl but it seems it may well just be the best available option at the moment as DNSSEC could do with an overhaul too first.
Re: [gentoo-dev] Re: USE flag "suid" in both use.desc and use.local.desc
On Mon, 31 Dec 2012 08:21:10 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > I was curious, however, as I'd been reading about running X as > non-root, I use some hackery to run startx on some systems as a normal user on linux and without suid. The only important things to me that break on these systems is hotplugging mice etc. and which could be quite easily fixed if it was worth the time. I've found a log out triggering a relaunch good enough with 0 complaints for now. You might be interested that the default on OpenBSD is for X to run as the X11 user and xdm to run as root and involves no hackery or issues but still some root priviledges.
Re: [gentoo-dev] Re: eudev project announcement
> We're drifting here, but the concept is that machine-local stuff like > configuration stays out of /usr, and generic distro stuff stays in > /usr. > > A webserver for site1 vs site2 would be identical in /usr, but > different elsewhere. That has always been the case. In fact people have tried to seperate /etc from / but it has proved too problematic. That's a different issue entirely. If the proposal was / (etc) /root /usr. I would be happy... if it worked. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [gentoo-dev] Re: eudev project announcement
On Wed, 19 Dec 2012 09:13:28 -0800 Greg KH wrote: > No, not at all, please see the web page that describes, in detail, the > problems that has been going on for quite some time now, with the /usr > and / partitions and packages. > http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken > > One good solution to this issue is to move everything into /usr, and > that's something that has wonderful benifits in the long run, and is > something that I expect all Linux distros to eventually implement. > Those that don't, will suffer because of it. > > Again, see the web page for why moving stuff into /usr is a good idea > for the reasons behind this. > http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge If either of those links allowed comments, the story they told would be very different. From memory notice how the second link skimps over the main driving force (point 4 again from memory).
Re: [gentoo-dev] Re: College Course in Gentoo Development
> People simply don't seem to realize that you can go away and > do something else while all that's happening Like servers I prefer build machines to be more secure dedicated build machines without a browser or X, so I expect it's a bit of a barrier for me. Having said that I haven't found the time to see how much time and resources are involved compared to Sabayon and how often yet whilst using libreoffice binaries. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [gentoo-dev] Moving our/portage stuff to var
On Mon, 17 Dec 2012 11:19:20 +0100 Tomáš Chvátal wrote: > The only reason why we have this currently in usr is that bsd ports > put their stuff in there and I suppose Daniel just did the same. >> +1 on /var/cache. >> >>> Agreed. >>>Bonus points if we consider suggesting to move it on a dedicated >>>file system ^^; /var sounds right but if /usr is still huge it may annoy some (like apt can) with smaller drives who now need lots of free space for new programs in both /usr and /var. Of course there is LVM. On OpenBSD the Auto partition map suggests /usr/ports /usr/src as seperate partitions as long as you have a fair amount of space. It possibly even suggests a seperate obj partition. The benefit being you can mkfs/newfs much quicker than deleting many many files. Security (DAC permission avoidance) and nuking more than what you wanted obviously needs consideration for that kind of function. So it's probably a user exercise?
Re: [gentoo-dev] Re: [gentoo-dev-announce] Summary Council meeting: Tuesday 11 December 2012
Firstly I use your longlasting 3.2 kernel currently though perhaps not for long as I'm switching distro to avoid systemd and thank you for the LTS work, however that won't stop me speaking my mind. _ > > Greg, can you write back to this message with specific examples of what > > would need to be customized so that separate /usr would work right > > without an initramfs? I have tried to explain multiple times that this > > is a mis-conception that udev caused it, but I am getting nowhere. > > It's not my job to do this, nor yours, or fix any of these issues. It's > up to the people who wish to keep a separate /usr partition without an > initramfs to do this work. So even though you keep stating things without being specific like udev is not a blocker, you have just admitted that the udev package does violate the Filesystem Hiearchical Standard as well as the latest draft when installing. I can understand following the current trend (some of which I agreed with) but what is the justification for that which didn't already have an optional solution? It's not your job?. I'd hope your unix spirit or atleast professionalism would be greater than this and realise that helping may save good devs time more than it costs you and realise that the generic goals may not be everyone's or even the long lasting correct ones and competition is good and not intended as a kick in the teeth or insult. p.s. embedded does not equal mobile and android uses a leaner init than /sbin/init and experiments posted to the buildroot list found systemd to be slower, guessed to be due to increased cycles but perhaps memory usage on even some mobile level processors which accounts for a fraction of linux potential in embedded applications. POSIX compliance is also a requirement by some major industries. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
