On 10/01/14 19:47, Bill Spitzak wrote:
> I think "recording a window" sounds a lot like another output (as in a
> montior). Then all the existing multi-view stuff can be reused to
> duplicate the window into this output, including controlling whether
> child surfaces are shown.
Is this multi-view f
On 10/01/14 18:13, Martin Peres wrote:
> And who would manage the sandboxes? Systemd won't be able to because
> it is user applications.
I don't know how this will be done in the future, I can't predict that.
I suppose there will be some kind of sandbox manager just like we have
virtual machine man
On 10/01/14 17:10, Pekka Paalanen wrote:
> What you call capturing a window, is just capturing a sub-rect of the
> screen for me. For me, capturing a window is a different thing, it
> gets the original window contents.
Okay, window capturing is probably not the right word to describe it.
It's ess
On 10/01/14 14:56, Martin Peres wrote:
> Please provide a detailed explanation for that and tell me how likely
> it is to ever end up upstream.
If by 'upstream' you mean the kernel: I don't think anything new is
needed, actually. Create a separate directory in /run/user/1000 for each
application, u
On 10/01/14 09:54, Pekka Paalanen wrote:
> I think it is realistic on good platforms, and also essential for
> performance. Needs to be tried out, of course.
X11 does capturing by simply copying the buffer to a SHM image. This
takes about 2ms for a 1920x1080 frame. That's perfectly usable,
consider
On 10/01/14 04:32, Jasper St. Pierre wrote:
> Here, run this program. You can audit it, it won't steal your
> credentials, but it doesn't take a screenshot of the desktop, and is
> fairly convincing. It would probably even fool me. It's X11, simply
> because that's easier than writing a raw Wayland
ame goal but totally different opinions
about how we should get there. I believe sandboxing is the future, and
is required for a secure desktop, so I want a protocol that is
compatible with sandboxing (future-proof, essentially). You want a
protocol that is already secure without sandboxing. And I believe that
such a protocol would be totally impractical and obsolete once
sandboxing is ready.
Let's put it this way: In order to get a secure desktop, we either need
to ensure that every single application we run is trustworthy (what we
try to do now), or we need sandboxing. Do you agree?
Maarten Baert
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
s don't seem to care anymore, the little security benefit
> it could have renders the whole system useless. UAC is just proving
> that an MLS security policy ultimately resolves into running
> everything into the highest privileged mode.
It's nice to see that we can at least agree on t
be trusted' model
is just not realistic.
And yes, your trust in the browser is totally misplaced because it is
trivial to compromise it. That's why I said that we need SELinux or
cgroups to create some sandboxing mechanism, before we can even start to
think about details like screenshots.
Maarten Baert
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
ry desktop uses BGRX or BGRA anyway), but dealing
with whatever weird formats some applications might want to use will be
a nightmare. The compositor already has to convert the buffer to the
screen format when it is drawn, so it's much easier and probably also
mor
t more sense, at least it is a lot more flexible
than requiring the recording application to be launched by the same key
press that starts the recording (which would effectively force me to
split my application into two separate processes, and then I would have
to
ucts it to do
so) and malicious programs won't get access to it.
I predict that any decision made now will be useless until sandboxing is
implemented, and obsolete after that ...
PS: A malicious program can rename /run/user/1000/wayland-0 and replace
it with its own socket, which allows a man-in-the-middle attack. How are
we going to deal with /that/, without a sandboxing mechanism?
Maarten Baert
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
icant number of normal use cases. You cannot design a secure
desktop that is fully idiot-proof and still usable. You have to assume
that the administrator knew what he was doing when he installed
application X, and trust that application to do what the user wants.
Maarten Baert
__
launching desktop files simple.
In my opinion desktop files and Wayland config files have a very
different purpose. The desktop files are there for convenience, they are
simply shortcuts for common actions that would otherwise require a
terminal. The Wayland config files OTOH are a security featur
On 03/01/14 03:27, Sebastian Wick wrote:
> Am 2014-01-03 02:19, schrieb Maarten Baert:
>> Okay, so the path in the config file is indeed the path to the
>> executable that will be launched by the Wayland compositor, and not
>> the path of the executable that _sends the
way to use Wayland
protocols and this new authentication API, so how hard is it for the
developers to write a 5-line INI file and put that in the right
directory? Do you really want to add a second authentication API that
adds potential security issues, just so dev
'm not saying
that we should use polkit, but I think there should be only one
mechanism, not two.
Is it acceptable for the Wayland protocol to have polkit as a dependency
for the authentication API?
Maarten Baert
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Wayland will need both, just like X11 has both:
the former is XGrabKey (which has a lot of problems and limitations that
I hope Wayland will solve), and the latter is the XTest extension. The
first one is probably more important though, so let's focus on that first.
Maarten B
pplication full path in a
> directory writable only by root
> (/etc/wayland/accepted-screenshoters.d/appname for example). The
> compositor would check all files in this directory before launching the
> application (or load the list of allowed applications at startup).
I
two possible solutions:
> - the screenshooter_shoot request could carry a serial which the done
> event sends back later
> - the screenshooter_shoot returns a screenshoot object which has the
> done event
The first solution is very simple and wou
e to help
where I can to add the thinks I need to add full Wayland support to my
application.
Maarten Baert
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
21 matches
Mail list logo
