Announcement

Collapse
No announcement yet.

GNOME Wants To Sandbox Applications Too

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

  • GNOME Wants To Sandbox Applications Too

    Phoronix: GNOME Wants To Sandbox Applications Too

    As another item that was discussed last week in Brussels during the GNOME Developer Hackfest is sandboxing of GNOME applications. GNOME developers already decided they want applications written in JavaScript but as another security measure they want to begin sandboxing applications...

    http://www.phoronix.com/vr.php?view=MTI5NDQ

  • #2
    What has sandboxing to do with a specific desktop? Isn't that, what Selinux and Company is made for?

    Comment


    • #3
      Originally posted by oleid View Post
      What has sandboxing to do with a specific desktop? Isn't that, what Selinux and Company is made for?
      I don't see the point. With this model they're following Chrome OS apps model, which is rather limiting.

      I'd prefer to see some elegant solution on the linux desktop to emulate BlackBerry's Balance (single user with work and personal space sandboxing), which could be done with LXC, I think.

      Comment


      • #4
        yeah?

        So the gnome and systemd cabal is pushing for an IPC mechanism in the kernel. Performance, security and features are probable gains. Can this go to mainline linux? Maybe. Attempts have failed before but this time it is another story.

        Does everybody want a linux IPC to rule them all? I doubt it.

        Comment


        • #5
          Unlike a lot of the GNOME team's recent botched decisions, I don't actually think this is a horrible idea. I wouldn't mind seeing sandboxed apps in a desktop computing environment, if it was done without being too annoying.

          Comment


          • #6
            Yeah right...

            given that sandboxing has worked extremely well so far everywhere else, I have complete trust that it will work this time too:
            - http://www.vupen.com/demos/VUPEN_Pwning_Chrome.php
            - http://arstechnica.com/security/2012...urity-sandbox/
            - http://www.extremetech.com/computing...a-magic-bullet
            - http://securitywatch.pcmag.com/none/...t-of-sandboxes

            Comment


            • #7
              Originally posted by oglueck View Post
              Totally agree, and in the same spirit, I've seen encryption broken somewhere else, so encryption is certainly worthless:
              - http://arstechnica.com/security/2012...ttps-sessions/

              Comment


              • #8
                In order to talk with the sandboxes app we need a IPC model that handles the domain transition between the namespaces. This implies the kernel being involved, so we have been looking (again) at getting some form of dbus routing support into the kernel. Hopefully this will work out this time.

                We also talked about implementing something similar to the Intents system in android as a way to allow sandboxed applications to communicate without necessarily knowing about each other. This essentially becomes a DBus service which keeps a registry of which apps implements the various interfaces we want to support (e.g. file picking, get-a-photo, share photo) and actually proxies the messages for these to the right destination. We had a long discussion about the name for these and came up with the name “Portals”, reflecting the domain-transition that these calls represent.
                This sounds strikingly similar to how android does IPC. Here is a nice document about that.

                Comment


                • #9
                  Originally posted by zoomblab View Post
                  This sounds strikingly similar to how android does IPC. Here is a nice document about that.
                  The text you're quoting already says the idea comes from Android.

                  Comment


                  • #10
                    Ugh

                    Ugh, I see no benefits and only downsides. It will be even slower, introduce new bugs, and provide no real security IMO. But this seems to be the trend in gnome, let's take what works well, break it, remove any useful features, add a 1000 new bugs, do tons of random pointless things, add features that are broken and useless and make it run as slow as humanly possible.


                    Ok, maybe I am exaggerating a bit. I have just gotten more and more annoyed with this sort of #@*(Y&(# over the last few years.

                    Hey I got an idea, let's have all gnome apps written in a new scripting language, let's called it Magic Gnome Script, (MGS), that script is then interpreted threw a runner, written in javascript, running inside a special gnome app viewer, running in a virtual environment, running inside...

                    Comment


                    • #11
                      Originally posted by funkSTAR View Post
                      So the gnome and systemd cabal is pushing for an IPC mechanism in the kernel. Performance, security and features are probable gains. Can this go to mainline linux? Maybe. Attempts have failed before but this time it is another story.

                      Does everybody want a linux IPC to rule them all? I doubt it.
                      There you have Android's "binder" IPC. But they probably want something more powerful like d-bus

                      Comment


                      • #12
                        Originally posted by andresmi View Post
                        Ugh, I see no benefits and only downsides. It will be even slower, introduce new bugs, and provide no real security IMO. But this seems to be the trend in gnome, let's take what works well, break it, remove any useful features, add a 1000 new bugs, do tons of random pointless things, add features that are broken and useless and make it run as slow as humanly possible.


                        Ok, maybe I am exaggerating a bit. I have just gotten more and more annoyed with this sort of #@*(Y&(# over the last few years.

                        Hey I got an idea, let's have all gnome apps written in a new scripting language, let's called it Magic Gnome Script, (MGS), that script is then interpreted threw a runner, written in javascript, running inside a special gnome app viewer, running in a virtual environment, running inside...
                        So instead of standing by the sideline, participate. Within GNOME we already work together with kernel developers and we will reach out to other desktop environments. We also track bugs using Bugzilla for many years, so 1000 new bugs is verified to be not true at all.

                        In any case, everything you say is obvious bullshit.

                        Comment


                        • #13
                          Originally posted by andresmi View Post
                          Ugh, I see no benefits and only downsides. It will be even slower, introduce new bugs, and provide no real security IMO. But this seems to be the trend in gnome, let's take what works well, break it, remove any useful features, add a 1000 new bugs, do tons of random pointless things, add features that are broken and useless and make it run as slow as humanly possible.
                          I think the big benefit is that you might actually get ISVs to package their applications for Linux. The current status is highly sub-optimal, as you are probably aware of.
                          I don't think the ability to run applications that are not packaged this way is going away.
                          Slower? Seems like there will be some magic going on when the app is started, but after that there shouldn't be any performance hit. Unless you have read something I missed, in which case you are welcome to enlighten me.

                          Comment


                          • #14
                            Originally posted by kigurai View Post
                            The current status is highly sub-optimal, as you are probably aware of.
                            It is MUCH worse than that. Probaly more like "shitty fucked poo". Having N distros packaging 10^X packages is so wrong on so many levels that I cry. Give me a bundle and give me a sandboxed enviroment to contain any stupidity. No more is needed. Systemd and in-kernel IPC(dbus as already suggested) is like 90% of the work.

                            Comment

                            Working...
                            X