back to article Linux distros haunted by Polkit-geist for 12+ years: Bug grants root access to any user

Linux vendors on Tuesday issued patches for a memory corruption vulnerability in a component called polkit that allows an unprivileged logged-in user to gain full root access on a system in its default configuration. Security vendor Qualys found the flaw and published details in a coordinated disclosure.  Polkit, previously …

  1. HildyJ Silver badge
    Linux

    Eyes

    While Linux and Open Source do have a considerable advantage over closed operating systems and software because of all the eyes on the code, this points out that the eyes are mostly looking at the present and future.

    The Polkit bug went unnoticed for 12+ years because the initial eyes missed it and subsequent eyes assumed what was already there was fine.

    We have efforts to maintain old code (xkcd's random person in Nebraska)

    But a concerted effort is needed to fund and implement a review of old code as well.

    1. Snake Silver badge

      Re: Eyes

      That's a dramatic statement of policy (and marketing) shift in F/OSS, and a good one. Recent years have proven that "We have more eyes on the code!" only means 'We have more eyes directed towards our [future] goals, but not necessarily reviewing our past work'.

    2. This post has been deleted by a moderator

      1. Snake Silver badge

        Re: OpenBSD

        "What got out of it is that linux is for bitches and dumb ones at that and people should use OpenBSD even though it is not always bulletproof per se either it is more secure than Linux."

        For me, this only sounds like more of the 'mine is better than yours' OS attitude that got Linux into its current problems of finding bugs in decades-old code. Rather than see that all code decays, and should therefore always be reviewed over time, Linux devs and aficionados fully believed that their code base was inherently "better" only because it was indeed F/OSS.

        Since they always believed in their "more eyes on the code" mantra, they felt that fundamentally someone, not necessarily themselves, would be doing the work of keeping the code base bug free.

        Since the work must have been done previously, during some earlier time, because of course sometime would have noticed a problem because there were so many eyes on the code and of course those eyes belonged only to the l33t H4x0rs working in the kernel, why would we ever need to review older code??

        1. ComputerSays_noAbsolutelyNo Silver badge

          Re: OpenBSD

          "Rather than see that all code decays, and should therefore always be reviewed over time"

          I don't really agree with the first part: why would code decay?

          The code doesn't change over time, it's only that assumptions turn out to be wrong, or previously overlooked bugs are found and identified. However, all flaws were always there.

          However, I fully agree with the second part: code, no matter how recent or old, should always be reviewed. Firstly, because we always learn more about the underlying assumptions of the code, we find bugs and edge cases that weren't previously considered. Secondly, our techniques for finding bugs evolve, and this is most important for old code. Old code may have been tested and reviewed to death by the means that were available back then, but in the mean time new techniques were developed, e.g. automated fuzzing and other computational abuse.

          1. Def Silver badge
            Headmaster

            Re: OpenBSD

            I don't really agree with the first part: why would code decay?

            The code itself might not change, but the environment in which it is run changes, programming languages evolve with time, system libraries change, programming paradigms change, and what was considered acceptable practice once upon a time can be frowned upon today.

            Let's take an extremely simple example:

            if( strlen( password ) < 10 )

            {

            error = "Your password is too short.";

            return false;

            }

            That would have worked fine when password was assumed to be ASCII. But feed it a single emoji combination encoded in UTF8 and suddenly you have single "character" passwords.

            1. badflorist

              Re: OpenBSD

              ?? U+0000 is located in the same spot as ASCII's 0x00, and no other UTF-8 characters contain a '\0' to delimit a string, so strlen() should work identically. Are "combinations" different? Can you give an example?

              Granted, I don't juggle UTF-8 often in C, but with small libraries for embedded projects not using an equivalent sizeof() on user strings is very risky (when you only have 512 bytes, you just can't assume anything :-/).

              1. Def Silver badge
                Headmaster

                Re: OpenBSD

                strlen returns, essentially, a byte count until the null terminator.

                For ASCII and other character sets where one byte maps to one character this is the same as the character length.

                The UTF8 encoding scheme of the Unicode standard, however, uses more than one byte to represent most characters. (The bottom 127 characters are identical to ASCII, characters with hex values lower than 0x800 require two UTF8 code points, characters below 0x10000 require three code points, and any character over 0xFFFF requires four.)

                Emoji characters occupy the character ranges above 0x1F300, so all base emoji characters require at least four code points in UTF8. However, there's a Zero Width Joiner character (0x200D - three UTF8 code points) that can be used to combine multiple emoji together to create a composite glyph.

                So for the single emoji character "family: man, woman, girl boy", you would encode it with the following Unicode characters: 0x1F468 0x200D 0x1F469 0x200D 0x1F467 0x200D 0x1F466, which when encoded as UTF8 (which I leave as an exercise for the reader) would result in a 25 byte string - plus the null terminator.

                So in my original dummy example, you could type a single Unicode emoji and the password system would accept it as being sufficiently long to be accepted.

                A lot of operating systems use UTF8 as their standard encoding scheme these days. I wonder how much broken software out there makes this assumption?

                1. Def Silver badge

                  Re: OpenBSD

                  To clarify: A lot of the time you don't need to care - you do just want the byte count and strlen is perfectly fine. Sometimes, however, you do need to make the distinction between code points and characters.

          2. breakfast
            Alien

            Re: OpenBSD

            Nobody knows why code decays, that's one of the great mysteries of the world. What happens to it? How does code that worked perfectly one day suddenly not work the next day? When that happens and you find the solution which indicates the code could never have worked, but it definitely worked yesterday, what is going on?

            I'm not one to arbitrarily invoke the paranormal, but when all rational explanations have been exhausted...

            1. Terry Barnes

              Re: OpenBSD

              Expiration of presumptions. When someone writes code they make presumptions about the world. Those things eventually change and the code breaks.

              As an inexhaustive list: years start with ‘19’. VAT is 15%. Filenames take the form 8+3. The U.K. is in the EU. East and West Germany are different countries. The dialling code for London is 01. All burgers sold in McDonalds contain meat.

              1. John Brown (no body) Silver badge

                Re: OpenBSD

                Or, of course, the build tool chain changes even though the source hasn't. Maybe a compiler has been made "more intelligent" and optimises that old code in a different way, even with absolutely no other change in the environment. Maybe it optimised away a clever coding trick because it thinks the result will always be NULL when in fact it's a vital bit of code. The source remains the same even if the binary might be different from last time you compiled it.

              2. Anonymous Coward
                Anonymous Coward

                Re: OpenBSD

                Here's another: systemd is wonderful.

                1. Fruit and Nutcase Silver badge
                  Joke

                  Re: OpenBSD

                  Linux distros haunted by Polkit[Poettering]-geist

                2. fnordianslip

                  Re: OpenBSD

                  I seem to recall that systemd has a dependency on polkit, at least did on RHEL.

                  1. jake Silver badge

                    Re: OpenBSD

                    Thankfully neither BSD nor Linux requires the systemd-cancer.

                    If anyone is wondering, polkit doesn't need the systemd-cancer either.

              3. Fred Daggy Bronze badge

                Re: OpenBSD

                Trick question. None of the burgers sold in McDonalds contain meat.

                1. phuzz Silver badge

                  Re: OpenBSD

                  Is it still meat if it comes from insects?

                  1. jake Silver badge

                    Re: OpenBSD

                    Of course. It's muscle tissue, isnt it? And tasty ... but don't take my word for it. You can easily find crickets online as "Chapulines", if you have the mind to do so. They taste and crunch like popcorn, with a hint of dried shrimp. I like to toss mine with a little chili powder (usually Jalapeno, but I sometimes go hotter). Lime zest is also nice.

          3. Crypto Monad

            Re: OpenBSD

            > code, no matter how recent or old, should always be reviewed

            In particular, code that is setuid root (like pkexec and sudo); and any other code that runs with elevated privileges.

      2. MacroRodent
        Boffin

        Re: Eyes

        Note that in this respect OpenBSD acts contrary to standards. Surprising as it is, argc==0 is a valid situation. It is only a convention that the first argument is the program name. There can be no arguments at all. Programs that assume argc can never be zero are buggy.

        1. Dan 55 Silver badge

          Re: Eyes

          It was a requirement in the draft version of ISO C 99 to pass at least 1 in argc as the filename was put in argv[0], but this requirement was removed from the final version as there were already implementations that passed 0 and NULL (embedded?).

          As a result of that POSIX was changed so passing at least 1 in argc the filename in argv[0] when calling the exec family of functions was recommended instead of obligatory.

          link

          Programs that assume argc can never be zero are buggy.

          Most programs assume that stdin, out, and err point to something useful, but apparently they shouldn't do that either. From the same link:

          Applications should not execute programs with file descriptor 0 not open for reading or with file descriptor 1 or 2 not open for writing, as this might cause the executed program to misbehave. In order not to pass on these file descriptors to an executed program, applications should not just close them but should reopen them on, for example, /dev/null. Some implementations may reopen them automatically, but applications should not rely on this being done.

          1. Paul 195
            FAIL

            Re: Eyes

            The "many eyes" hypothesis about the better quality of OSS code has been pretty well disproved over the last few years. At this point it's hard to believe that Linux is somehow inherently more secure than the latest versions of Windows 10 or Windows Server. Software is hard, operating systems are even harder, and they are always going to have holes to exploit. So the question is not whether the many eyes are catching bugs, but how fast and effectively you can remediate problems, and how robust are your software supply chains.

            And yes, software decays. Not in the sense that the actual bits rot away, but the context the software runs in changes all the time. Software that isn't regularly updated gets trapped on obsolete and insecure platforms because at some point it can't move to a newer one. Paradigms change as we learn different things, or have to run at a different scale. If you based your application on CORBA 20 years ago, you were on the cutting edge. Now that same application is hard to support legacy. Effectively, it's decayed.

            1. Dan 55 Silver badge

              Re: Eyes

              This is more of a problem with a spec that permits recommended behaviour which so much software follows to that it doesn't even occur to most people that there is other equally correct unconventional behaviour, so they don't code that software with the unconventional behaviour in mind.

              There are two real problem in present-day software: 1) Developers groking specs and 2) Do the specs make sense or are they ambiguous enough to cause problems?

          2. martinusher Silver badge

            Re: Eyes

            >Most programs assume that stdin, out, and err point to something useful, but apparently they shouldn't do that either.

            Surely all that will happen if you try to read or write to a file descriptor that's identifying a valid device is that you'll get an error. In any event it should never cause a system problem. There is a notion that when you're accepting input from a process you make no assumptions about what's going to be given to you, accepting any old junk and (worst case) just ignoring what doesn't make sense. (Likewise you make the minimum demands on other programs, only providing them with valid data and queries.)

            (So, in this case, its the responsibility of the library to return an error if the descriptor is invalid and the program to at least check for the error and take appropriate action.)

            (It looks like all this fuss is about the kludgey practice of shelling programs from a from web server to process data requests. This opens the door to all sorts of parameter abuses.)

            1. Dan 55 Silver badge

              Re: Eyes

              Who knows, maybe e.g. opening 0 for writing or 1 and 2 for reading is screwy enough to make an application do something it shouldn't?

              Perhaps someone's got time to test this idea? (i.e. I don't.)

              1. emfiliane

                Re: Eyes

                You would have to dig pretty deep to find a runtime that wouldn't outright reject stdin for not having FMODE_READ or stdout/stderr for not having FMODE_WRITE, or not reject a call to read() or write() or their equivalents the same way. I can't get it to happen despite some tricks to bypass usual initialization, but I'm also only testing on modern Windows and Linux... but there's many more minimally maintained buildchains and over-clever toolkits ripe for the picking out there.

                I could drop down to driver level, but once you can do that, it's game over anyway.

          3. chasil

            Re: Eyes

            Perhaps following OpenBSD's approach, and ignoring the standards on all POSIX platforms might generally improve security?

            It would have caught this.

            "...but OpenBSD, he said, is not affected because the kernel won't execve() – execute a program by its pathname – if argc is 0."

            1. doublelayer Silver badge

              Re: Eyes

              It would have prevented this, yes, but it wouldn't necessarily catch other things like it. It happened that a thing OpenBSD decided not to do was required to exploit a bug in a program. This wasn't a security measure designed to prevent abuses of this nature, as a buggy program was required to make use of it. When the next security vulnerability comes along, it could just as easily exploit someone not adhering to a standard as rigidly doing so.

              1. david 12 Silver badge

                Re: Eyes

                OpenBSD does adhere to the standard -- and goes beyond it, with the explicit intention of being more secure. Being more secure than the minimum standard is/was indeed a security measure designed to prevent abuses of this nature.

                It is true that an application program that assumes OpenBSD level of security is not more secure by doing so

                1. doublelayer Silver badge

                  Re: Eyes

                  No, they are not adhering to the standard. The standard says that argc=0 is valid. They are refusing to accept that input. It's not valid input I care about, and the standard writers had considered making it invalid, but they did not. The OpenBsD implementation is using a modification of the standard where they don't adhere to that particular provision. This is fine, as long as we don't make too much of it. It helped in this case. However, when modifications are made, they can result in problems just as adherence can lead to problems. Bugs can exist anywhere, so programs should be reviewed more to catch the important ones. Standards can be changed to help with this, but making changes doesn't automatically do it.

            2. Dan 55 Silver badge

              Re: Eyes

              In this case OpenBSD is enforcing strictly confirming POSIX, it isn't going against POSIX standards.

    3. david 12 Silver badge

      Re: Eyes

      Where Linux and Open Source do NOT have an advantage over Windows is in the (cultural) dependence on Environment Variables.

      I got sick of pointing out that for Windows builds, other methods offered more secure alternatives: I was assured that the use of environment variables was safe because the user was not privileged.

      1. badflorist

        Re: Eyes

        "Where Linux and Open Source..."

        Your first sentence... so much wrong.

        "I got sick of pointing out..." <-- this

        1. david 12 Silver badge

          Re: Eyes

          If, as seems to be the case, you are alleging that Linux in particular, and Open Source in general, do not place 'environment variables' in a more critical place than is the case for Windows and Windows application programming --- then you are only demonstrating your ignorance of Windows and Windows application programming

          1. badflorist
            Pint

            Re: Eyes

            "..demonstrating your ignorance of Windows..."

            WOW! I usually don't tear up like this, but thank you... thank you very much! Have a great day!

    4. jake Silver badge

      Re: Eyes

      Don't make mountains out of molehills. It's just another bug. It has been patched, and faster than commercial software usually is, by a wide margin. No more problem.

      There will be more bugs in ANY codebase as large as a Linux distribution. When found, they will be patched just as quickly as this one was.

      ::shrugs::

      1. Skiron

        Re: Eyes

        Yes, and to be honest, who will be affected by this? I doubt any business allows any old user to connect to a Linux terminal, and even if they did that person still has to have the knowledge to manipulate it to get root.

        1. sabroni Silver badge
          Thumb Up

          Re: I doubt any business allows any old user to connect to a Linux terminal

          Yes! This is how you do security!

          1. jake Silver badge

            Re: I doubt any business allows any old user to connect to a Linux terminal

            That was quite kind and gentle of you, sabroni. Mellowing with age?

            1. TimMaher Silver badge
              Windows

              Re: I doubt any business allows any old user to connect to a Linux terminal

              Yes but it’s the young users who are the most dangerous.

        2. John Riddoch

          Re: Eyes

          Why do we care about this bug that allows a user to run unprivileged code? It couldn't possibly be used to do anything nasty...

          The point is that once you have an unprivileged shell on a target machine, having a method to escalate to root is the next step. The best crackers don't rely on one vulnerability, they chain together multiple vulnerabilities to get where they want to be.

          1. Anonymous Coward
            Anonymous Coward

            @John Riddoch - Re: Eyes

            Yeah, but let those hackers work as hard as possible and spend a lot of time to get those root privileges. Why offer them an easy way ?

            Remember, defence also includes retarding the attackers as much as possible.

        3. Anonymous Coward
          Anonymous Coward

          Re: Eyes

          "Yes, and to be honest, who will be affected by this? I doubt any business allows any old user to connect to a Linux terminal, and even if they did that person still has to have the knowledge to manipulate it to get root."

          But there are a reasonably large number of places which do have multi-user systems for valid reasons, and those users aren't always entirely trustable (eg, universities). And even an 'inquisitive' user on a box where they are the only user could still get up to some naughtiness if they could become root.

          1. Anonymous Coward
            Anonymous Coward

            Re: Eyes

            apt purge snapd -y

            1. Anonymous Coward
              Anonymous Coward

              Re: Eyes

              WTF? When did rm get replaced with bloatware?

              1. jake Silver badge

                Re: Eyes

                "When did rm get replaced with bloatware?"

                Not replaced with, augmented by. Was the logical answer when bloatware authors decided to scatter files in so many sub-directories that using scripts to remember where they are became necessary.

                For rather small values of logical, of course.

                Sad, innit?

                1. phuzz Silver badge

                  Re: Eyes

                  when bloatware authors decided to scatter files in so many sub-directories

                  So since at least 1979 when Unix 7th edition was released then?

                  1. jake Silver badge

                    Re: Eyes

                    Yeah, but back then bloated monstrosities like EMACS (sorry, rms!) were the exception, not the rule. Even Sendmail was four years out in '79 ... and Apache's httpd was 16 years away!

                    Argumentum ad absurdum usually makes one look silly, and upsets the pig.

        4. Terry Barnes

          Re: Eyes

          Once an exploitable vulnerability exists all that is required for it to be exploited is time.

        5. doublelayer Silver badge

          Re: Eyes

          "I doubt any business allows any old user to connect to a Linux terminal, and even if they did that person still has to have the knowledge to manipulate it to get root."

          Businesses do allow users to connect to terminals. True, few of them are still using the one big computer that does everything and everyone's accounts are launched on it, paradigm, but root on one server can be used to collect data useful in breaking into others.

          The other side of this is that it might not be someone using this to attack a system that they've already been granted non-root access to. If an external attacker manages to get into a system through some other exploit, but they only have access to a particular user's area, they could use a bug like this to get somewhere else.

        6. vogon00

          Re: Eyes

          person still has to have the knowledge to manipulate it.

          Knowledge is a rarity these days.....pasting from the WWW (stackoverflow et al) seems to be the current substitute. I wonder how many people who use/abuse stackoverlow actually understand what a stack overflow really is?

    5. John Robson Silver badge

      Re: Eyes

      Because there is no way that this would have gone unnoticed at Microsoft or Apple - we never hear about bugs in *their* code.

      1. Handy Plough

        Re: Eyes

        Just, wow! This is exactly the arrogance of the 'many eyes' apologists! Just think of the shit storm that there would be were this Windows/macOS!

        Think of the many 1000's of unpatched servers out there affected by this. FFS people, drop you religious zeal and see the bigger issue; FOSS, while giving you the ability to review the code, is no better than closed source, because the many clearly do not review the code!

        1. Graham Cobb Silver badge

          Re: Eyes

          No, that is simply a false statement. FOSS, with the ability to review the code, is much better than closed source for two very important, and objectively true, reasons:

          1) Many people can, and do, review code. Of course, not all code gets reviewed very often - particularly older code - and reviews certainly don't spot all bugs. But much code gets reviewed and many bugs are spotted.

          2) Once a bug is found, many people do review the code, review and improve the fix, review other similar code in other programs, add this issue to their internal list of gotchas to avoid, add regression test cases to automated testing, etc. And, of course, if the bug is important to them they can fix it themselves if they need to - for example if they are running an old, unsupported version for some reason.

          1. LDS Silver badge

            "Many people can, and do, review code."

            That's plain wishful thinking. Actually, those reviewing the code now is vulnerability hunters, often for profit. Those reviewing code on a voluntary basis look to be very few. So a bug can the there for twelve years. And that happens with what is the most financed FOSS project - think what happens with the others with little or no resources.

            Closed source code is reviewed as well because there are cases when people are actually paid to do that. Closed source doesn't mean it is stored strongly encrypted when only the compiler can see it. It just means it is not publicly published.

            Bugs are fixed the same way in open and closed source code - often, the developers are the same.

            "they can fix it themselves if they need to"

            Another myth - most users don't have nor the skill nor the tooling to fix code themselves, especially old versions. Sure, they could paid someone if they could find him or her.

            1. Graham Cobb Silver badge

              Re: "Many people can, and do, review code."

              You misunderstand. I am not saying that every piece of FOSS code has been reviewed by many people. Although I am fairly confident that for modern code it gets reviewed by many more people than equivalent proprietary code does (as major FOSS projects nowadays impose code review obligations on code changes that result in many more reviewers than the 2 or 3 in a typical vendor's development team). What I am saying is that when comparing large codebases, the FOSS implementations generally get more review than the proprietary implementations.

              No single function necessarily gets a lot of review in either environment. And there are plenty of bugs in 12-year-old code in both environments. However, bugs are much more likely to be found, fixed, and stay fixed in the 12yo FOSS code than in the proprietary code.

              How many people have ever even seen the equivalent "change mode to root" switching code in Windows? Compared to the number that have now seen it in polkit? Hopefully there isn't a similar bug in that Windows function. We can now be confident that there isn't a similar bug in any of the similar functions in the major FOSS world because this bug will have prompted many people to look at that code in polkit, and the similar code in sudo, su, and other FOSS implementations.

              The "many eyes" effect is very real. It isn't perfect at all, but it drives an ever improving code quality level that just can't be matched by proprietary teams.

              1. LDS Silver badge

                "bugs are much more likely to be found, fixed"

                Have you any evidence of that? Just saying it doesn't make it real. Moreover when you can make money by finding exploitable vulnerabilities only, how many bugs which aren't vulnerabilities aren't reported?

                "generally get more review than the proprietary implementations."

                Again, have you evidence of that? Moreover, is the number of review that matters, or the quality of them?

                "Compared to the number that have now seen it in polkit?"

                Those numbers might not be that much far apart. The problem is exactly that. But their own developers, there are not many other people looking at the source code of most projects, especially those with enough skills to be able to quickly spot bugs.

                "The "many eyes" effect is very real."

                Actually, the bugs that are emerging in these days look to show it is not real at all. Software with too few developers and little support. People using code and giving nothing back - not even bug reports, and no fixes. The problem is the lack of resources and incentives, and the "someone else's problem" attitude.

                1. Graham Cobb Silver badge

                  Re: "bugs are much more likely to be found, fixed"

                  You obviously aren't familiar with the process of modern FOSS code review. It isn't about big security issues like this - those are the ones that get headlines but the "many eyes" process doesn't just (or even mostly) help with that.

                  I am not a kernel developer but I follow the btrfs development mailing list. Every patch to btrfs goes through that list. Every patch is reviewed by several of the key developers. So far, that is similar to the proprietary process (except that the reviewers work for different companies - itself a small benefit). But every patch is also reviewed by a lot of other people - some, like me, are just interested techies - some are very experienced system managers who have dealt with bugs in btrfs for many years, build their own kernels, and help track down problems - some manage the largest btrfs deployments in the world (think about places like Facebook) and have a lot of experience of how things fail in their world. All these people contribute to the review and the testing - before the code is even sent to Linus for the rest of the world to see.

                  The effect is that most of the bugs found by these people are not major security issues - they are functional issues, deadlock issues, hangs, performance slowdowns, etc. Many, many of those are found by interested parties in the community, long before the code gets out.

                  Personally I have only contributed one patch to btrfs. That was to fix a small functional issue - that probably would only affect less than 1% of users (still a lot!). But I have participated in other discussions and testing that have resulted in improvements to the code.

                  Yes, there are many FOSS projects that don't get the review, testing and support that the kernel does (and even parts of the kernel that don't get much interest - I submitted a long-asked-for improvement to a small and unloved part of the kernel and it took months to get it reviewed and accepted) and we need to improve that. But that is nothing to do with the "many eyes" issue.

                  FOSS has plenty of faults but there is no point trying to deny that the "many eyes" process is an important advantage for FOSS - which has to be weighed against the various disadvantages. This particular incident is a great example of the considerable benefit it gives.

              2. Terry Barnes

                Re: "Many people can, and do, review code."

                “ I am not saying that every piece of FOSS code has been reviewed by many people. ”

                For a building to be secure, every door must be locked.

                You are as secure as your weakest link, not your strongest.

          2. Terry Barnes

            Re: Eyes

            Point 2) is only true if the person who finds it has good intentions. Don’t presume that people looking for mistakes are doing so out of the goodness of their hearts.

        2. John Robson Silver badge

          Re: Eyes

          "Just, wow! This is exactly the arrogance of the 'many eyes' apologists! Just think of the shit storm that there would be were this Windows/macOS!"

          Erm - it's regularly Windows, and slightly less frequently MacOS.

          There is no shitstorm, nor even a significant murmuring.

          At least here we can patch any systems, including any that are out of official support - and we don't need to take on board 47 other "essential" fixes which ech introduce a dozen changes to other bits of the system just to grab this one.

          FOSS isn't perfect, noone says it is - but this isn't something which highlights the benefits of closed source as some seem to claim. It highlights the requirement to have defense in depth.

        3. Bob9911

          Re: Eyes

          This says it all. Open source does NOT equate to better, more secure code. As long as people are coding things, there will be bugs

          1. dafe

            Re: Eyes

            I think there was a baby in that bathwater.

        4. Anonymous Coward
          Anonymous Coward

          @Handy Plough - Re: Eyes

          Sorry, pal, but for the money I'm paying to Apple and Microsoft that sh%t storm would be entirely justified.

          Besides, in case you were not aware, there's a well known security mantra saying "Trust but verify". Contrary to code from Microsoft and Apple, nobody is preventing you to check and validate OSS code before use, you said it yourself. Now to add insult to injury, on top of being guilty for those bugs, the OSS developers are guilty of not reviewing the code for you.

          I don't mind for proprietary software to be better than Open Source. It's all about making the right choice based on your needs.

    6. Dan 55 Silver badge

      Re: Eyes

      The Polkit bug went unnoticed for 12+ years because the initial eyes missed it and subsequent eyes assumed what was already there was fine.

      I'd have thought Red Hat which has the money to constantly run automated fuzz testing on every one of their executables would have been doing this for years. Sadly not, they're as bodgy as the rest of us.

      1. Anonymous Coward
        Anonymous Coward

        Re: Eyes

        >Red Hat which has the money to constantly run automated fuzz testing

        Yeah - but if Lars is the one parsing the output he'll discard anything that doesn't confirm his ideas.

    7. Jaybus

      Re: Eyes

      And if we can't afford a review of all old user-mode code, then at least a review of code designed for SUID root might be in order.

  2. Skiron
    Unhappy

    Polkit

    This is another RedHat thing that got foisted on to everybody else, isn't it?

    1. Gene Cash Silver badge

      Re: Polkit

      It's another systemd abomination apparently, but according to Wikipedia, Fedora was the first to have it.

      According to the Debian wiki "it is sometimes referred to as "the sudo of systemd".

      1. jake Silver badge

        Re: Polkit

        Except it was in development before the systemd-cancer existed.

        1. Graham Dawson

          Re: Polkit

          Except it was completely re-written and renamed in 2012, after systemd had established itself. It broke API compatibility in order to better align with the systemd way of doing things, and likely simplified the exploitation of this bug in the process.

          1. jake Silver badge

            Re: Polkit

            Bastardization of the concept doesn't negate the origin.

      2. Dave559 Silver badge

        Re: Polkit

        And Wikipedia wisely says (note the second sentence!):

        It is also possible to use polkit to execute commands with elevated privileges using the command pkexec followed by the command intended to be executed (with root permission). However, it may be preferable to use sudo, as this command provides more flexibility and security, in addition to being easier to configure.

    2. Anonymous Coward
      Anonymous Coward

      Re: Polkit

      interestingly enough, AWS Linux (based on centos) doesnt have pkexec.

      1. jake Silver badge

        Re: Polkit

        How about polkitd?

    3. AdamWill

      Re: Polkit

      It's kinda weird constantly seeing this argument *in the same week* as people are also moaning about how nobody is paying F/OSS developers.

      Yes, lots of important F/OSS things are written by people who work at Red Hat. You know why that is? Because Red Hat hires people who write important F/OSS things and pays them to do it. You know. That thing people keep saying should be happening more. systemd is a "Red Hat thing that got foisted on everybody else" because Red Hat saw that Lennart was writing important stuff (at the time, pulseaudio and avahi) and hired him to do it full time. polkit is a "Red Hat thing that got foisted on to everybody else" because Red Hat hired a bunch of the GNOME developers in order to let them work on GNOME full time.

      Would F/OSS be in a better place if Red Hat *didn't* hire people and pay them to work on important F/OSS projects full time? Would you prefer that?

      1. Paul Crawford Silver badge

        Re: Polkit

        Maybe - but really it is the arrogance of certain individuals who want everything re-written in their own image.

        So stuff that was OK/secure many years ago gets re-implemented and a whole new set of bugs created, and since much of this is PID-1 stuff, has root vulnerabilities.

        1. AdamWill

          Re: Polkit

          The point of polkit is to *reduce* the amount of stuff that can have root vulnerabilities. At a very big-picture level, the point of polkit was to replace consolehelper/userhelper. The major limitations of consolehelper/userhelper were how coarse it was - it ultimately just decided whether a user was allowed to run things as root or not, and ran the entire thing as root if the user was allowed to do so. So back in Ye Olde Days when some people seem to think everything was so highly secure, a graphical admin tool that needed root privileges for something - say, a user account creation tool, or a keyboard layout configuration tool - had to be run entirely as root in order to work. Everything it did, it did with root privileges. And if a user needed to be able to run that tool, they *also* ipso facto had to be given the ability to run anything else as root. No finer-grained policy was possible.

          One major advantage of polkit is that it allows for much more fine-grained policies than "can this user run things as root or not?" The other major advantage is that it makes it much simpler for applications to run *mostly* unprivileged and then gain only specific necessary privileges for operations that need them. The user management tools in KDE and GNOME can run mostly as the user that runs them, then gain only (for example) the privileges they need to create user accounts, when the user who's running them actually clicks on the "Create User" button. If they don't do that, the app doesn't try to gain any privileges at all.

          pkexec isn't really the main point of polkit (which is why, as another commenter noted, it's possible to ship polkit without it). It's not like it exists because someone decided they wanted to rewrite sudo. No distro that I'm aware of actually suggests using pkexec interactively to run things as root (they all recommend sudo for that). It was initially included, AFAIR, to accommodate the move from consolehelper for apps whose authors weren't willing or able to rewrite them to the better model of doing things; the idea was it was better to accommodate those apps *somehow* so that it was possible to get rid of consolehelper, rather than keep it around forever. (If you're wondering why things couldn't be rejigged to just run those apps via sudo, it's a good question and I don't remember for sure; I think it was to do with wanting to keep the experience of launching the apps from a menu and a graphical authentication prompt appearing, but I might be forgetting something).

          It's definitely pretty bad that pkexec turned out to have this bug all along. It might even be a reason for distros to reconsider whether they still need to ship pkexec (I don't know, off the top of my head, if there's an obvious reason to keep it around at least by default any more).

      2. Joe W Silver badge

        Re: Polkit

        I sort of agree - but completely changing the philosophy of how stuff should work (do one darned thing and do it well), there are programs that want to be the be-all-end-all-thing. Having these pushed aggressively upset many people - there are problems with the monolithic approach, and the interconnected parts of the thing, and (for me) finding the cause for problems and then resolving them is much more complex (and aggravating - why does component $X influence component $Y?!) than it used to be - maybe it's my age showing.

        The problem is that it is conceivable there do exist components / programs that should be pushed from certain vendors, and that would make everybody happy in the long run, making sysadmins' tasks easier, removing dependencies or old cruft - alas, fixing the old stuff is not sexy.

        (and don't get me started on pulseaudio...)

      3. Doctor Syntax Silver badge

        Re: Polkit

        Right idea, bad choice.

    4. Steve Graham

      Re: Polkit

      It's a mechanism for bypassing normal Unix-style permissions. I've always regarded it as an accident waiting to happen, and make sure that none of my Linux boxes have it.

    5. Warm Braw Silver badge

      Re: Polkit

      The basic problem here is that there is a historic all or nothing privilege system and the mitigations for that (like polkit) involve running significant chunks of code in an elevated privilege context in which any error is potentially very serious.

      A long-standing bug with similar consequences was found in sudo.

      I don't think RedHat is responsible for a fundamental design error made in the 1970s - or possibly earlier.

      1. Doctor Syntax Silver badge

        Re: Polkit

        As far as I can remember so long ago the basic design, or at least V7 which was my earliest version, was a bit more nuanced.

        Yes you could use root to do things such as administer printers but you could also use a different UID to do that such as lpadmin for the printers. "Do one thing and do it well" in operation.

        It meant that in the case of an installation with multiple operators the privileges could be shared out appropriately by giving an operator the specific passwords they needed.

        That seemed to be Too Complicated so everyone tended to get the root password whether they needed it or not.

        That was Too Insecure so then we got sudo and pkexec.

        1. jake Silver badge

          Re: Polkit

          "It meant that in the case of an installation with multiple operators the privileges could be shared out appropriately by giving an operator the specific passwords they needed."

          Still can, if you know what you are doing. Slackware makes it (relatively) easy.

      2. Peter Gathercole Silver badge

        Re: Polkit @Warm Braw

        Given the history of UNIX, and the fact that the initial movers and shakers had got completely fed up with some of the design extremes that were going into Multics, I would say that in the initial work providing the split between privileged and non-privileged was a design choice, not a design error.

        As I understand it, the privilege model of Multics, although good in principal, put far too much demand on the systems of the time. And the UNIX privilege model fitted in well with the USER and SUPERVISOR hardware privilege model of the PDP-11 system, which fed into a lot of UNIX and C design.

        Should it have been changed? Well, it was extended (the concept of groups was added to UNIX quite early, but which the full scope has been forgotten over the years). UNIX does not have to be all-or-nothing, but it has always required to have one user which could do everything. It's the implementations that has made anything that was not being run by an ordinary user run by root, but it does not need to be like that.

      3. dafe

        Re: Polkit

        Polkit is not a mitigation of user and group based capabilities.

        It completely by-passes that system for the purpose of privilege escalation, and while the filters can be as fine-grained as any setuid command, Ulrike sudoers polkit's always run as root. It's a root-kit.

        1. AdamWill

          Re: Polkit

          "Ulrike[sic] sudoers polkit's always run as root. It's a root-kit."

          This isn't accurate. polkit itself doesn't run as root. The design of polkit is, as the documentation says, that it "provides an authorization API intended to be used by privileged programs (“MECHANISMS”) offering service to unprivileged programs (“CLIENTS”)". The "privileged programs" can be privileged in any way - that could mean that they're running as root, but it could also mean that they have much more restricted elevated privileges (by running as some other user with specific privileges, or using a more advanced mechanism like capabilities). polkit itself is effectively just a "referee": its job is to help the privileged program decide whether it should offer a service to a less-privileged one.

  3. bazza Silver badge

    CLI strikes again...

    This is not the first time that a program has caused havoc by failing to parse its command line parameters properly.

    Given that there are myriad ways in which interfaces can be automatically generated from a specification, with little room for abuse in the implementation (especially for ASN.1, JSON, and XSD/XML done properly), it is ridiculous that we still cling on to the CLI as a way of having one program call another. There is a lot of advantages in using something like Dbus compared to passing parameters on a CLI.

    1. Roland 2

      Re: CLI strikes again...

      Agreed that config/argument parsing should be done by a well tested library, but nothing much to do with CLI arguments vs. json config files.

      There are plenty of poor ways to hand parse a config file too, with associated security issues.

      Using an adequate library (think argparse in python, or clap in Rust) is not only safer, it also brings good error messages in case of misuse, arguably better that a security hole.

      1. bazza Silver badge

        Re: CLI strikes again...

        Good arg parsing libraries are useful but don't solve the whole problem. There's no good way for the caller and program to k ow for sure that they're using the same understanding of what args mean what. Generally it's up to a human to t read a man page, see what's changed.

        This matters quite a lot.

        For example there was some years ago a HDD encryption package for Linux which was the usual collection of scripts calling other scripts and programs. Problem was that the program that did the actual encryption changed its CLI but not in a way that broke the scripts. The result was that null passwords were used to encrypt data, regardless of what the user typed in.

    2. Androgynous Cupboard Silver badge

      Re: CLI strikes again...

      Oh please. Code generated automatically from a spec language is a filthy thing. It's so abstracted away from the norms of whichever language it's written for that it fails the "principle of least surprise", which is one of the most important things a developer needs to write good, secure code.

      I say this from the perspective of both 30 years of coding and a recent battle with the Xero API, which is generated from a spec language, and has been completely reworked several times since inception (requiring corresponding reworks of my integration, when I have better things to do). It's my current poster child for how not to do API development.

      Plus you mentioned ASN.1 and didn't wash your mouth out. I've seen abuse of ASN.1 that would make the Church blush.

      1. Graham Cobb Silver badge

        Re: CLI strikes again...

        Ah. ASN.1 BER. The memories.

        In the late 1980's I implemented a big and important (for us, at the time) protocol specified in ASN.1. I played with the ASN.1 compilers of the time and gave up on getting any useful code out of them. But I did create my own library (for my application) of tools to parse, check and generate valid ASN.1 BER (although the semantics of the messages were all handled in ordinary code). And I wrote lots of regression tests just to check the validation (and added to them if I found a bad message that got through).

        The one massively useful thing which ASN.1 encoding gave me was that I could (and did) check every message which arrived for encoding correctness, with arbitrary-sized messages, removing issues like incomplete messages, buffer overflows, etc from that code. After that initial check, I knew I had the whole message in memory, that there were no incomplete sequences, no incorrectly formatted integers, etc. I also applied some of my own implementation-specific rules (such as requiring that every integer would fit in 64 bits, and imposing maximum lengths on certain types of sequences and object IDs). All before any of the semantic processing started.

        ASN.1 isn't user friendly, but it is implementor friendly. I assume (hope?) that the tools have got a lot better in the last 30+ years.

        1. Anonymous Coward
          Anonymous Coward

          Re: CLI strikes again...

          Well, if you're from the Java world the answer is a resounding "no" to your last question. BouncyCastle API is the usual approach, and it's hairy. ASN.1 is an amorphous blob of possiblities, so if you've set yourself the goal of covering all those possibilities, you're going to wind up with an awful lot of amorphous code.

          We used it for a time then did the same as you, jacking it in for our own ASN.1 parser. The fun part wasn't the parsing so much, it's the many "interesting" interpretations of the higher specs such as PKCS#7 or X.509 that have sprouted like mushrooms. For anyone that thinks X.509 is a "standard" in the modern sense of the word, I beg to differ.

        2. bazza Silver badge

          Re: CLI strikes again...

          Yes, the commercial tools have got a lot better in the last 30 years.

          You could do worse than take a look at the modern commercial tools, and the modern ASN. 1 standards. The commercial tools now have reasonable language support (C, C++, C++ using std lib, Java. C#, even Python). The ASN.1 spec now includes XML and JSON as wire formats (which gives interesting interop options). All major OSes and platforms are supported.

          OSS options are more limited. But the ESA has something called the TASTE framework, which is quite interesting. There's a fairly good OSS C implementation / compiler on GitHub too.

          You can these days have an agile, single version of the interfaceing truth specification in the core of one's project, and safely make late breaking significant interface changes for minimal risk and effort. You're relying on the tools to either deal with changes through recompilation, or pointing out where your interface spec change has broken something. Once you that pattern of working established, it's pretty slick and dev friendly, largely because you can minimise code review effort for such a change.

          Google Protocol Buffers gets a lot more attention, but doesn't have any notion of constraints on value or length. Which is a real pity because otherwise GPB is moderately useful.

          1. Androgynous Cupboard Silver badge

            Re: CLI strikes again...

            If you need to serialize arbitrary binary data I would highly recommend CBOR over GPB or Msgpack. Vendor independent, very good library support and simple enough to roll-your own if you prefer (I did). Plus it handles indefinite-length items, which makes it great for streaming.

            With application layers like COSE on top (basically JSON Web Tokens in CBOR) it's also starting to encroach on territory held by ASN.1.

      2. TheFifth

        Re: CLI strikes again...

        As someone who has also engaged in battle with the Xero API, I completely agree. When I was battling with it, the documentation was incomplete, most of it was auto-generated, and the examples included simply didn't work. I've noticed it's improving in that regard, but still has a long way to go. I've also had to rework the implementation many times too to keep pace with their constant shifting.

        1. Anonymous Coward
          Anonymous Coward

          Re: CLI strikes again...

          Yes, that documentation is an absolute joke. I ended up running their Jar through a decompiler so I could see the magic formula for the various constructs their code generated came up with.

      3. This post has been deleted by its author

      4. bazza Silver badge

        Re: CLI strikes again...

        There's a lot code generation tools around these days, they get used quite a lot. Things like Google Protocol Buffers are perhaps a bit more hipsterish than ASN.1...

        The C++ code generated by GPB is pretty horrific, but I think that that simply reflects the fact that C++ simply doesn't have the capacity or neatly express some of the concepts embodied in the GPB schema language. Generally I've found that higher level languages generally get neater generated code, because there's more the language can provide that the code generator doesn't have to implement for itself.

        Eg having a variable length array in C takes a ton of code. Even in C++, it's a bunch of code. C++ with the STL does a lot better, because now there's vectors and such. C#, Java and Python just have that sort of thing natively, and the code generator can just declare one.

        Things can still be problematic, eg a JSON schema can express something that is like a C union, but C# does not have unions, so the JSON schema code generators for C# that I've seen just refuse to implement it. Probably all is well in Python.

        No I didn't wash my mouth out! It's matured like a good wine, or Parmigiano cheese.

    3. Anonymous Coward
      Anonymous Coward

      Re: CLI strikes again...

      The biggest advantage in passing arguments via DBus rather than directly through the operating system is that you have a bigger attack surface. Exploiting parser bugs is no longer limited to newly forked processes, it can also affect already running daemons now, including the DBus daemon itself.

      1. bazza Silver badge

        Re: CLI strikes again...

        That's certainly true, if a parsing flaw is present. But if the parsing component is flawless, and rigidly so, then it's robust and won't let mistakes propagate. Dbus uses a schema driven code generator, I'm assuming with the need for interface parsing rigour in mind (though it lacks value constraints).

        It basically comes down to what's better, getting a single parser generator correct or there being a myriad different ways individual devs and libraries go about parsing. It's probably more efficient to focus on the single parser generator (per language).

    4. Lunatic Looking For Asylum

      Re: CLI strikes again...

      It's not the CLI.

      It's the usual suspects desire to have everything graphical in front of the CLI that's causing this.

      I really hate Red Hat for this very reason. When I build a system I don't want X installing on it, I don't want a graphical boot or install process, I don't want avahi (lets sniff round the network and look for shares and printers...) installing on it, I don't want graphical tools on it for basic system admin tasks. polkit et. al. is in place to allow circumvention of the command line and good system management practice.

      When I build a server I want nothing on it apart from the bare minimum required to perform its functions, everything extraneous to that just adds another attack vector.

  4. Paul Johnston
    FAIL

    Oh dear

    I know 9 is essentially in beta-ish and this is just a learning box, nothing in production but doesn't inspire confidence

    (base) [paulj@e-uxxmcasspj5 ~]$ cat /etc/redhat-release

    CentOS Stream release 9

    (base) [paulj@e-uxxmcasspj5 ~]$ ./cve-2021-4034--2022-01-25-0936.sh

    This script (v1.0) is primarily designed to detect CVE-2021-4034 on supported

    Red Hat Enterprise Linux systems and kernel packages.

    Result may be inaccurate for other RPM based systems.

    This script is meant to be used only on RHEL 6-8.

  5. Anonymous Coward
    Anonymous Coward

    Shudders at "learning" PolicyKit

    My introduction to LInux was Ubuntu, which I installed on a media server.

    It took me a long time (because the documentation was ... well lets leave it there) to work out why there were some programs that would not run in my NoMachine session - even though it was direct to the console.

    Eventually I found PolicyKit and the XML files where it defines what to do for privilege escalation.

    I actually wrote up my findings and posted them on the (now defunct) UbuntuForums

    Every so often I'd get a grateful email from someone else who had been similarly baffled.

    It was also an early introduction to the Linux community.

  6. FuzzyTheBear
    Pint

    Oook :)

    Before i read about it here i already had a libpolkit update applied. didnt know why it was there .. just glad to see the patch was already done before i read about it. :D As far as fixing problems is .. that's one for the team cheers

  7. Colin Guthrie
    Facepalm

    Policy can still let you down

    I remember a while back that I found a several years old bug in the policy file for a tool called sectool which was a RedHat thing. It's policy file ultimately gave all users the right to do things as root. So install a package to audit security and it messes up your security! Fun times.

    Polkit is handy overall tho'. Gives flexibility to run a restricted set of tasks very cleanly with defined API on the system/user buses (speaking to appropriate daemons running as other users etc). It's pretty clean (from a usage perspective) generally even if the JS interpreter might seem like overkill. Running commands via the CLI is just one use case for polkit - sudo certainly can't do 90% of what polkit can. The same policy mess up I found (which was pre the big polkit rewrite IIRC) could have just as easily been a file packaged in /etc/sudoers.d/ folder.

  8. fredesmite2
    WTF?

    Why do you broadcast this for ?

    " Let's reveal how you can fuck up a system "

    1. Doctor Syntax Silver badge

      Re: Why do you broadcast this for ?

      How about "Let's reveal there's an important upgrade to apply"?

    2. dafe

      Re: Why do you broadcast this for ?

      Those who want to fuck up your system already know from the CVS or had the exploit ready for over twelve years.

      Those whose system might get fucked up by this probably don't subscribe to the CVS.

  9. bombastic bob Silver badge
    Unhappy

    FreeBSD appears to be affected

    I checked the pkexec.c source (from a recent install) and it has the flaw in it. Also verified that under FreeBSD it's possible to use execve() with zero arguments causing 'argc == 0' (which is a valid condition as someone else pointed out). Assuming argc must always be >= 1 is just bad code.

    Fortunately, with the source available, I can patch it myself.

    1. -tim

      Re: FreeBSD appears to be affected

      pkexec isn't installed on most FreeBSD systems. It doesn't appear to be in the base system install and likely in polkit package.

  10. Nate Amsden Silver badge

    lucky

    I manage about 750 linux systems. checked this morning after verifying the ubuntu security advisories and saw none of my systems have this package installed.

    So maybe installed by default but not a required package. good news there anyway.

  11. symgryph

    Glad I use Alpine!

    I recently tried to update a 'test' of rocky linux (the successor to Centos), only to find that by default the Updates repo didn’t work due to a change on deadrat's side of 4k rsa sigs. Additionally, I now see silly things like 'polkit' suid nonsense, and I am SO GLAD I use alpine:

    1. Small

    2. uses MUSL instead of GLIBC (smaller attack surface)

    3. systemd OPTIONAL (sometimes one needs systemd evil, but I don't want deviltry enforced on me)

    4. upgrade EASY and painless

    5. LBUBACKUP saves all my settings and etc things automagically

    Busybox does take a bit of getting used to, but you can selectively install GNU things if you really need them. My systems 'just work' without breaking (unlike deadrat, where my system obliterated itself due to a faulty kernel update).

    Also openrc is nice, but its not quite as easy to use as systemd with unit files, but 99% of the time I can find a system package that already has one. So I often don't need to deal with beyond service blah enable.

    1. jake Silver badge

      Re: Glad I use Alpine!

      "sometimes one needs systemd evil"

      Can you provide examples that are not contrived just to prove the point?

      To date, I have never, not once, seen a place where the systemd-cancer is needed.

      1. jtaylor

        Re: Glad I use Alpine!

        "'sometimes one needs systemd evil' Can you provide examples?"

        It's useful to be able to manage service dependencies and groups of services. This is why I liked the Service Management Facility in Solaris

        Note that I don't claim systemd is the correct solution to anything, only that I have found cases where it helps to manage services at a higher level than SysV init.

        1. jake Silver badge

          Re: Glad I use Alpine!

          Sounds to me like you want a service manager, which doesn't really belong in an init when you think about it.

          1. jtaylor

            Re: Glad I use Alpine!

            I don't care if init calls a service manager. I want the web server to start after boot, and if it depends on a database back-end, I want the database up before the web server starts, and if the database depends on an NFS mount, I want that volume mounted first. I don't want every startup task to be serialized, but get the dependencies right.

            1. jake Silver badge

              Re: Glad I use Alpine!

              I've been doing exactly that on Slackware for about 25 years. No big deal :-)

    2. Lunatic Looking For Asylum
      Pint

      Re: Glad I use Alpine!

      I like Alpine too Have one of these.

      I'm not too chuffed with musl not supporting utmp/wtmp, their reasons seem spurious at best Scroll down here https://wiki.musl-libc.org/faq.html for more info)

      Administering big multi user systems, seeing who is online and having a history of logins/reboots etc. is pretty fundamental.

      1. jake Silver badge

        Re: Glad I use Alpine!

        I prefer pine to alpine, but will happily use either.

        Spurious? Sounds to me more like paranoia ... or, more likely, somebody got caught red-handed.

  12. Anonymous Coward
    Anonymous Coward

    Meanwhile in the NHL

    PK SUBAN unvailable for comments.

    1. jake Silver badge

      Re: Meanwhile in the NHL

      What's hockey got to do with all this?

      1. FernTheConcentricGuy

        Re: Meanwhile in the NHL

        "This vulnerability has been hiding in plain sight for 12+ years and affects all versions of pkexec..." That's his first name minus exec. Sencondly to gain root access in linux you would have to use the su ie super user command with a password; that's his second name if you add ban.

        1. jake Silver badge

          Re: Meanwhile in the NHL

          Syntax error, unable to parse. 2 minute minor.

  13. Lorribot

    Can't wait for the 100 odd Linux based appliances that will likely need updating with patches from the many different vendors for their specific flavours of Linux, some will be quick, others not so, some will likely not bother or even know as the bloke that did has left due to cost cuts, IR35. Each one will have to manually patched, with attendant Change requests and lots of out of hours work no doubt.

    Thus is the life of those supporting Linux in the real world rather the nice idealized one were you have a few servers running the distro of your choice and you can just grab and update as required.

    Unlike Windows were you just point it at a WSUS server and all your servers are up to date in what ever time scale you choose.

    1. Dante Alighieri Bronze badge
      Pint

      Appliances v Servers

      Sorry, I may have misunderstood but you talk about appliances and Io(.shi)T then about windows servers.

      oranges v screwdrivers methinks.

      You have seen the 12 Borks etc etc etc

      embeded WinCE on rides in Disneyland will also be sorted for all CVE (wish I'd had a camera for the Bork!^3 when I was riding it)

      YMMV. ----> icon

    2. bombastic bob Silver badge
      Meh

      polkit is really only necessary if you have a GUI and something like Gnome or Mate uses it for whatever reason. Although I think systemd may need it, it may also be optional without a GUI installed.

      So most (if not all) of those Linux appliances may not be affected. But RPi OS would be, if you're using it as a touch screen. So there you have it.

      (risk assessment as needed if the device is networked or not)

  14. Anonymous Coward
    Alien

    Bury it in the desert. Wear gloves

    Polkit problem is that it was designed by people with brains made of cabbage. Open source can not help you if your brain is made of cabbage. Open source can not help you if you use software written by cabbage brains.

    Imagine you wanted to look at a system and statically answer question: 'who has privileged access?'. If that system uses polkit then to answer this question you must evaluate programs written in JavaScript. JavaScript is trivially Turing-complete language so in general that means that you can not answer this question, even in principle. Oh, yes, now cabbage-brains will say that no, is not halting problem here as computations are time limited. Yes: time-limited, so now to know if a computation completes or times out and fails you will need merely to store the entire physical state of the machine running it and replay it, accounting for any possible events which may alter timings like, well, anything. Which is a problem you can solve in principle ... if you can store the entire state of the past light cone of the computation, which is laughably impossible.

    Solution to polkit is simple: bury it in the desert. Wear gloves.

    1. Anonymous Coward
      Anonymous Coward

      Re: Bury it in the desert. Wear gloves

      "Polkit problem is that it was designed by people with brains made of cabbage."

      Precisely how does this differ from the people who designed Linux ? Inasmuchas that train wreck has a design.

      For many years now Linux has resembled a rag-bag of random stuff thrown together by monkeys with typewriters. One word proof: systemd.

      1. bombastic bob Silver badge
        Linux

        Re: Bury it in the desert. Wear gloves

        Fortunately, systemd is NOT Linux. I would say that some of the desktops (talking about YOU, Gnome) resemble the rag bag etc. in at least SOME ways, but fortunately Linux itself and the standard POSIX utilitiesl do NOT (they seem very well designed and reliable, to me).

        1. jake Silver badge

          Re: Bury it in the desert. Wear gloves

          Not only is the systemd-cancer NOT Linux, Linux doesn't even need the systemd-cancer to operate.

          GNOME is simply awful. Why people continue to propagate the charade is beyond me.

          Yes, the basic utilities included with all (most?) Linux distributions (and BSD) are very well designed, secure, and reliable.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like

Biting the hand that feeds IT © 1998–2022