libnotify-like notifications
267 views
Skip to first unread message
Jan Beerden
Aug 18, 2012, 6:46:43 AM8/18/12
to qubes...@googlegroups.com
Hello
I'm wondering if it would be possible to have libnotify-like notifications from the different appvm's?
Maybe even passing notifications to dom0's notification daemon?
Kind regards
Jan Beerden
I'm wondering if it would be possible to have libnotify-like notifications from the different appvm's?
Maybe even passing notifications to dom0's notification daemon?
Kind regards
Jan Beerden
Marek Marczykowski
Aug 18, 2012, 9:09:38 AM8/18/12
to qubes...@googlegroups.com, Jan Beerden
On 18.08.2012 12:46, Jan Beerden wrote:
> Hello
>
> I'm wondering if it would be possible to have libnotify-like notifications
> from the different appvm's?
> Maybe even passing notifications to dom0's notification daemon?
notification-daemon can be started in VM - then the notifications will have
> Hello
>
> I'm wondering if it would be possible to have libnotify-like notifications
> from the different appvm's?
> Maybe even passing notifications to dom0's notification daemon?
colorful frame :)
You can start it by executing /usr/libexec/notification-daemon, or copy
/usr/share/applications/notification-daemon.desktop to /etc/xdg/autostart (in
template VM) to have it automatically started at VM boot.
--
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab
Radosław Szkodziński
Aug 18, 2012, 9:12:37 AM8/18/12
to qubes...@googlegroups.com
Jan Beerden <j...@janbeerden.be> napisał:
If a really central mechanism is desired, the protocol will have to be pretty restrictive, more so than clipboard one.
R.Sz.
Vít Šesták
May 21, 2015, 3:37:51 AM5/21/15
to qubes...@googlegroups.com
I've made a proof-of-concept. I've significantly modified statnot (just few of the original Python code remained) to forward all notifications to a RPC endpoint in dom0. Just title, appname and message body are supported. The fields are separated by newline, which allows injection. Maybe this is not critical, but I'd like to fix it. There is, of course, also a RPC, which is currently written in Bash and which sanitizes (or probably rejects) the input if there is invalid UTF-8 sequence, parses the input and passes it to notify-send.
https://gist.github.com/v6ak/6ef6768103587bc273fb
Priorities:
1. Rewrite the RPC endpoint
2. Make a better protocol and fix the injection
3. Write some more friendly installation manual and/or create a pull request to Qubes
4. Support more fields, including actions
5. Support images (tricky to make it secure)
## 1. Rewrite the RPC endpoint
I don't think I can do much in Bash, so I'd like to rewrite it. Bash was great for prototype, but it is likely bad for future modifications. I see three options what to rewrite it to:
a. Python
b. Ruby
c. Scala
Python would require almost no additional dependencies (mainly notify-python, which is in repo), but it is the language I am least familiar with from these three. It also has highest chances to be accepted by Qubes team, as they seem to already have much code in Python. Scala is the language I am most familiar with, but it would require a JVM, a Scala and java-gnome package (installed size: 137 MiB) and I guess this has the lower chance to be accepted of these options. Ruby seems to be somewhere between. I know Ruby better than Python, but not as much as Scala. And so on…
Note that Java does not like short-running apps, but I hope this could be solved, e.g. by using -Xint option or maybe nailgun-based daemon.
## 2. Make a better protocol and fix the injection
The current protocol does not handle newlines in notification title and so on. We need a better serialization. In Scala, I could just use DataInputStream, which should be safe and valid UTF-8 strings would be guaranteed. In Python, I am not sure what to use. Maybe a JSON? But that might be too large attack surface. Maybe struct.pack/unpack? I am not sure about security and safety, I just found it was vulnerable in the past (see https://www.exploit-db.com/exploits/31762/ ), but not sure about the present.
## 3. Write some more friendly installation manual and/or create a pull request to Qubes
At this stage, it would be likely mature enough for either being merged with Qubes or published with some installation manual.
I just published two scripts, but the installation is slightly more complicated. The q6-notification-proxy is intended to replace the notification daemon (e.g. notify-osd, mate-notification-daemon or whatever) in the AppVM. The rpc script is intended to be an endpoint in Dom0, but installing an endpoint requires adding a policy and a one-line service file. This is not complicated and if you would like to develop this, I can provide you some hints.
## 4. Support more fields and libnotify options, including actions
Actions would complicate the protocol, but I think it is reasonable to want a support for them.n't think
## 5. Support images (tricky to make it secure)
Nice to have and relatively complicated. We need to convert the image to RGB (in order to minimize attack surface) and somehow mix with the AppVM lock or AppVM color.
# Some general security considerations
* Notifications are transferred to Dom0 at this moment. I don't think to be bad. First, the LibnotifyVM gets inherently *some* trust, as notifications might contain something sensitive and it would likely allowed (in future) to perform some actions on AppVMs. But more importantly, I don't see a simple protocol handled by a memory-safe language with some utf-8 sanitization to be a significant attack surface. I don't think that the security benefits of a separate LibnotifyVM outweight all the overhead, but it is technically possible.
* Proper string encoding should be enforced in the RPC endpoint. It is in the current bash version and it should be enforced in the future version.
* Active/idle detection. If we implement some handlers of cancelled notification, any AppVM with permission to use notifications could make a notification with some short expiration. Some notification daemons (e.g. mate-notification-daemon) seem to start counting after some activity is detected, which would allow any AppVM with permission to use notifications to detect activity. Such malicious activity is however likely to be seen by user and assigned to the malicious AppVM. We can help the user by setting a minimal timeout.
* Notification flood. In KDE, a notification flood causes older notifications to be forgotten. But such attack is usually not high-risk and there is very high chance to find the malicious AppVM.
* Extremely large payloads. They could cause either a DoS (e.g. swapping and running Dom0 out of memory) or buffer overflow. None of these is desirable, but it should cause at most DoS with a correct notification daemon. Do we care? Note that there are some other opportunities for such attacks, like X11 windows.
Regards,
Vít Šesták 'v6ak'
https://gist.github.com/v6ak/6ef6768103587bc273fb
Priorities:
1. Rewrite the RPC endpoint
2. Make a better protocol and fix the injection
3. Write some more friendly installation manual and/or create a pull request to Qubes
4. Support more fields, including actions
5. Support images (tricky to make it secure)
## 1. Rewrite the RPC endpoint
I don't think I can do much in Bash, so I'd like to rewrite it. Bash was great for prototype, but it is likely bad for future modifications. I see three options what to rewrite it to:
a. Python
b. Ruby
c. Scala
Python would require almost no additional dependencies (mainly notify-python, which is in repo), but it is the language I am least familiar with from these three. It also has highest chances to be accepted by Qubes team, as they seem to already have much code in Python. Scala is the language I am most familiar with, but it would require a JVM, a Scala and java-gnome package (installed size: 137 MiB) and I guess this has the lower chance to be accepted of these options. Ruby seems to be somewhere between. I know Ruby better than Python, but not as much as Scala. And so on…
Note that Java does not like short-running apps, but I hope this could be solved, e.g. by using -Xint option or maybe nailgun-based daemon.
## 2. Make a better protocol and fix the injection
The current protocol does not handle newlines in notification title and so on. We need a better serialization. In Scala, I could just use DataInputStream, which should be safe and valid UTF-8 strings would be guaranteed. In Python, I am not sure what to use. Maybe a JSON? But that might be too large attack surface. Maybe struct.pack/unpack? I am not sure about security and safety, I just found it was vulnerable in the past (see https://www.exploit-db.com/exploits/31762/ ), but not sure about the present.
## 3. Write some more friendly installation manual and/or create a pull request to Qubes
At this stage, it would be likely mature enough for either being merged with Qubes or published with some installation manual.
I just published two scripts, but the installation is slightly more complicated. The q6-notification-proxy is intended to replace the notification daemon (e.g. notify-osd, mate-notification-daemon or whatever) in the AppVM. The rpc script is intended to be an endpoint in Dom0, but installing an endpoint requires adding a policy and a one-line service file. This is not complicated and if you would like to develop this, I can provide you some hints.
## 4. Support more fields and libnotify options, including actions
Actions would complicate the protocol, but I think it is reasonable to want a support for them.n't think
## 5. Support images (tricky to make it secure)
Nice to have and relatively complicated. We need to convert the image to RGB (in order to minimize attack surface) and somehow mix with the AppVM lock or AppVM color.
# Some general security considerations
* Notifications are transferred to Dom0 at this moment. I don't think to be bad. First, the LibnotifyVM gets inherently *some* trust, as notifications might contain something sensitive and it would likely allowed (in future) to perform some actions on AppVMs. But more importantly, I don't see a simple protocol handled by a memory-safe language with some utf-8 sanitization to be a significant attack surface. I don't think that the security benefits of a separate LibnotifyVM outweight all the overhead, but it is technically possible.
* Proper string encoding should be enforced in the RPC endpoint. It is in the current bash version and it should be enforced in the future version.
* Active/idle detection. If we implement some handlers of cancelled notification, any AppVM with permission to use notifications could make a notification with some short expiration. Some notification daemons (e.g. mate-notification-daemon) seem to start counting after some activity is detected, which would allow any AppVM with permission to use notifications to detect activity. Such malicious activity is however likely to be seen by user and assigned to the malicious AppVM. We can help the user by setting a minimal timeout.
* Notification flood. In KDE, a notification flood causes older notifications to be forgotten. But such attack is usually not high-risk and there is very high chance to find the malicious AppVM.
* Extremely large payloads. They could cause either a DoS (e.g. swapping and running Dom0 out of memory) or buffer overflow. None of these is desirable, but it should cause at most DoS with a correct notification daemon. Do we care? Note that there are some other opportunities for such attacks, like X11 windows.
Regards,
Vít Šesták 'v6ak'
Vít Šesták
May 21, 2015, 3:56:48 AM5/21/15
to qubes...@googlegroups.com
Well, there is one more security consideration. Some notification daemons parse HTML in some cases. The KNotify does this. This is very nasty, as this is not properly documented. I am not sure if this is fail of notify-send notification (which does not mention HTML) or if it is just some nasty extension of some notification daemons.
Regards,
Vít Šesták 'v6ak'
Regards,
Vít Šesták 'v6ak'
Marek Marczykowski-Górecki
May 21, 2015, 6:14:02 AM5/21/15
to Vít Šesták, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, May 21, 2015 at 12:56:48AM -0700, Vít Šesták wrote:
> Well, there is one more security consideration. Some notification daemons
> parse HTML in some cases. The KNotify does this. This is very nasty, as
> this is not properly documented. I am not sure if this is fail of
> notify-send notification (which does not mention HTML) or if it is just
> some nasty extension of some notification daemons.
Actually we use this feature/bug in some places - for example gpg
backend has name of calling VM bold. Also I'm not sure if this is a
feature or a bug.
Maybe there could be two services: Notify and NotifyHTML and you can
setup policy to allow the later one only for more trusted VMs?
>
> Regards,
> Vít Šesták 'v6ak'
>
> On Thursday, May 21, 2015 at 9:37:51 AM UTC+2, Vít Šesták wrote:
> >
> > I've made a proof-of-concept. I've significantly modified statnot (just
> > few of the original Python code remained) to forward all notifications to a
> > RPC endpoint in dom0. Just title, appname and message body are supported.
> > The fields are separated by newline, which allows injection. Maybe this is
> > not critical, but I'd like to fix it. There is, of course, also a RPC,
> > which is currently written in Bash and which sanitizes (or probably
> > rejects) the input if there is invalid UTF-8 sequence, parses the input and
> > passes it to notify-send.
> >
> > https://gist.github.com/v6ak/6ef6768103587bc273fb
Nice prototype.
As you've guessed, I vote for Python :)
> > ## 2. Make a better protocol and fix the injection
> >
> > The current protocol does not handle newlines in notification title and so
> > on. We need a better serialization.
Maybe just as now - 3 lines. But each encoded with base64? Of course
later it needs some sanitization:
- validate UTF-8
- filter/drop HTML tags and maybe some control characters
- some length limit
> In Scala, I could just use
> > DataInputStream, which should be safe and valid UTF-8 strings would be
> > guaranteed. In Python, I am not sure what to use. Maybe a JSON? But that
> > might be too large attack surface. Maybe struct.pack/unpack? I am not sure
> > about security and safety, I just found it was vulnerable in the past (see
> > https://www.exploit-db.com/exploits/31762/ ), but not sure about the
> > present.
> >
> > ## 3. Write some more friendly installation manual and/or create a pull
> > request to Qubes
> >
> > At this stage, it would be likely mature enough for either being merged
> > with Qubes or published with some installation manual.
> >
> > I just published two scripts, but the installation is slightly more
> > complicated. The *q6-notification-proxy*
> > <https://gist.github.com/v6ak/6ef6768103587bc273fb#file-q6-notification-proxy>
Maybe if the application requests some actions, just handle such notify
locally?
> > ## 5. Support images (tricky to make it secure)
> >
> > Nice to have and relatively complicated. We need to convert the image to
> > RGB (in order to minimize attack surface) and somehow mix with the AppVM
> > lock or AppVM color.
There is already such image converter, take a look at
linux-utils/core/imgconverter.py (or
/usr/lib64/python2.7/site-packages/qubes/imgconverted.py in VM).
But as above - I think it isn't high priority.
> > # Some general security considerations
> >
> > * Notifications are transferred to Dom0 at this moment. I don't think to
> > be bad. First, the LibnotifyVM gets inherently *some* trust, as
> > notifications might contain something sensitive and it would likely allowed
> > (in future) to perform some actions on AppVMs. But more importantly, I
> > don't see a simple protocol handled by a memory-safe language with some
> > utf-8 sanitization to be a significant attack surface. I don't think that
> > the security benefits of a separate LibnotifyVM outweight all the overhead,
> > but it is technically possible.
Even if we decide that we need LibnotifyVM, it's trivial change because
RPC policy supports redirection (so every notify RPC could be redirected
to notify VM, without any configuration in the calling VM.
> > * Proper string encoding should be enforced in the RPC endpoint. It is in
> > the current bash version and it should be enforced in the future version.
> > * Active/idle detection. If we implement some handlers of cancelled
> > notification, any AppVM with permission to use notifications could make a
> > notification with some short expiration. Some notification daemons (e.g.
> > mate-notification-daemon) seem to start counting after some activity is
> > detected, which would allow any AppVM with permission to use notifications
> > to detect activity. Such malicious activity is however likely to be seen by
> > user and assigned to the malicious AppVM. We can help the user by setting a
> > minimal timeout.
Maybe we can just don't give any feedback to the calling VM? Just like
do not support actions. But I'm not sure if this is a big problem.
> > * Notification flood. In KDE, a notification flood causes older
> > notifications to be forgotten. But such attack is usually not high-risk and
> > there is very high chance to find the malicious AppVM.
We can implement some per-VM rate-limit (like 20/min). But IMO we can
ignore the problem in first version.
> > * Extremely large payloads. They could cause either a DoS (e.g. swapping
> > and running Dom0 out of memory) or buffer overflow. None of these is
> > desirable, but it should cause at most DoS with a correct notification
> > daemon. Do we care? Note that there are some other opportunities for such
> > attacks, like X11 windows.
Size surely needs to be limited. Does dbus notification API specify any
size limit? Maybe we can use the same?
> >
> > Regards,
> > Vít Šesták 'v6ak'
> >
> > On Saturday, August 18, 2012 at 3:12:37 PM UTC+2, Radosław Szkodziński
> > wrote:
> >>
> >>
> >>
> >> Jan Beerden <j...@janbeerden.be> napisał:
> >>
> >> >Hello
> >> >
> >> >I'm wondering if it would be possible to have libnotify-like
> >> >notifications
> >> >from the different appvm's?
> >> >Maybe even passing notifications to dom0's notification daemon?
> >> >
> >> >
> >> >Kind regards
> >> >
> >> >Jan Beerden
> >>
> >> Normal notifications work well, but they might overlap if more than one
> >> is present at the same time.
> >>
> >> If a really central mechanism is desired, the protocol will have to be
> >> pretty restrictive, more so than clipboard one.
> >>
> >> R.Sz.
> >>
> >
>
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVXa/gAAoJENuP0xzK19csvUEH/0169aCTtLJyZCSYAKtGmqAv
u6hO5vWf1i5Z/tU/KyuAuhW2Gv9CgzQvmhb1EtTKVcYv9xyT/axCK64eILgmjaau
RvLwNa8YnZaV/IUkyPW7V/1vgdyPF0QUscQBFDNnc/mJVegB6e8kpzq1HOXTULVW
V6qxVJHnE/uJwcgB23FyvLUgluIDRJATP0vIXmSOWpDIlQts49PyV60iKLIeTmoq
6gydzTFxQfXDNGkq/qrnbdzaOYuxIdoVeAnUNLhYy3F69O7m1O8PTRIC6LGftNwV
+jA1tzU7hpUCBtFX1IBoTQtOys4dw3sYQ0ftis+yqVT8Lbfe6Xgd1ykqOKxamgw=
=uR4q
-----END PGP SIGNATURE-----
Hash: SHA1
On Thu, May 21, 2015 at 12:56:48AM -0700, Vít Šesták wrote:
> Well, there is one more security consideration. Some notification daemons
> parse HTML in some cases. The KNotify does this. This is very nasty, as
> this is not properly documented. I am not sure if this is fail of
> notify-send notification (which does not mention HTML) or if it is just
> some nasty extension of some notification daemons.
backend has name of calling VM bold. Also I'm not sure if this is a
feature or a bug.
Maybe there could be two services: Notify and NotifyHTML and you can
setup policy to allow the later one only for more trusted VMs?
>
> Regards,
> Vít Šesták 'v6ak'
>
> On Thursday, May 21, 2015 at 9:37:51 AM UTC+2, Vít Šesták wrote:
> >
> > I've made a proof-of-concept. I've significantly modified statnot (just
> > few of the original Python code remained) to forward all notifications to a
> > RPC endpoint in dom0. Just title, appname and message body are supported.
> > The fields are separated by newline, which allows injection. Maybe this is
> > not critical, but I'd like to fix it. There is, of course, also a RPC,
> > which is currently written in Bash and which sanitizes (or probably
> > rejects) the input if there is invalid UTF-8 sequence, parses the input and
> > passes it to notify-send.
> >
> > https://gist.github.com/v6ak/6ef6768103587bc273fb
> > ## 2. Make a better protocol and fix the injection
> >
> > The current protocol does not handle newlines in notification title and so
> > on. We need a better serialization.
later it needs some sanitization:
- validate UTF-8
- filter/drop HTML tags and maybe some control characters
- some length limit
> In Scala, I could just use
> > DataInputStream, which should be safe and valid UTF-8 strings would be
> > guaranteed. In Python, I am not sure what to use. Maybe a JSON? But that
> > might be too large attack surface. Maybe struct.pack/unpack? I am not sure
> > about security and safety, I just found it was vulnerable in the past (see
> > https://www.exploit-db.com/exploits/31762/ ), but not sure about the
> > present.
> >
> > ## 3. Write some more friendly installation manual and/or create a pull
> > request to Qubes
> >
> > At this stage, it would be likely mature enough for either being merged
> > with Qubes or published with some installation manual.
> >
> > I just published two scripts, but the installation is slightly more
> > <https://gist.github.com/v6ak/6ef6768103587bc273fb#file-q6-notification-proxy>
> > is intended to replace the notification daemon (e.g. notify-osd,
> > mate-notification-daemon or whatever) in the AppVM. The *rpc* script is
> > intended to be an endpoint in Dom0, but installing an endpoint requires
> > adding a policy and a one-line service file. This is not complicated and if
> > you would like to develop this, I can provide you some hints.
> >
> > ## 4. Support more fields and libnotify options, including actions
> >
> > Actions would complicate the protocol, but I think it is reasonable to
> > want a support for them.n't think
I'm not sure if this is good idea to have actions in this protocol.
> > adding a policy and a one-line service file. This is not complicated and if
> > you would like to develop this, I can provide you some hints.
> >
> > ## 4. Support more fields and libnotify options, including actions
> >
> > Actions would complicate the protocol, but I think it is reasonable to
> > want a support for them.n't think
Maybe if the application requests some actions, just handle such notify
locally?
> > ## 5. Support images (tricky to make it secure)
> >
> > Nice to have and relatively complicated. We need to convert the image to
> > RGB (in order to minimize attack surface) and somehow mix with the AppVM
> > lock or AppVM color.
linux-utils/core/imgconverter.py (or
/usr/lib64/python2.7/site-packages/qubes/imgconverted.py in VM).
But as above - I think it isn't high priority.
> > # Some general security considerations
> >
> > * Notifications are transferred to Dom0 at this moment. I don't think to
> > be bad. First, the LibnotifyVM gets inherently *some* trust, as
> > notifications might contain something sensitive and it would likely allowed
> > (in future) to perform some actions on AppVMs. But more importantly, I
> > don't see a simple protocol handled by a memory-safe language with some
> > utf-8 sanitization to be a significant attack surface. I don't think that
> > the security benefits of a separate LibnotifyVM outweight all the overhead,
> > but it is technically possible.
RPC policy supports redirection (so every notify RPC could be redirected
to notify VM, without any configuration in the calling VM.
> > * Proper string encoding should be enforced in the RPC endpoint. It is in
> > the current bash version and it should be enforced in the future version.
> > * Active/idle detection. If we implement some handlers of cancelled
> > notification, any AppVM with permission to use notifications could make a
> > notification with some short expiration. Some notification daemons (e.g.
> > mate-notification-daemon) seem to start counting after some activity is
> > detected, which would allow any AppVM with permission to use notifications
> > to detect activity. Such malicious activity is however likely to be seen by
> > user and assigned to the malicious AppVM. We can help the user by setting a
> > minimal timeout.
do not support actions. But I'm not sure if this is a big problem.
> > * Notification flood. In KDE, a notification flood causes older
> > notifications to be forgotten. But such attack is usually not high-risk and
> > there is very high chance to find the malicious AppVM.
ignore the problem in first version.
> > * Extremely large payloads. They could cause either a DoS (e.g. swapping
> > and running Dom0 out of memory) or buffer overflow. None of these is
> > desirable, but it should cause at most DoS with a correct notification
> > daemon. Do we care? Note that there are some other opportunities for such
> > attacks, like X11 windows.
size limit? Maybe we can use the same?
> >
> > Regards,
> > Vít Šesták 'v6ak'
> >
> > On Saturday, August 18, 2012 at 3:12:37 PM UTC+2, Radosław Szkodziński
> > wrote:
> >>
> >>
> >>
> >> Jan Beerden <j...@janbeerden.be> napisał:
> >>
> >> >Hello
> >> >
> >> >I'm wondering if it would be possible to have libnotify-like
> >> >notifications
> >> >from the different appvm's?
> >> >Maybe even passing notifications to dom0's notification daemon?
> >> >
> >> >
> >> >Kind regards
> >> >
> >> >Jan Beerden
> >>
> >> Normal notifications work well, but they might overlap if more than one
> >> is present at the same time.
> >>
> >> If a really central mechanism is desired, the protocol will have to be
> >> pretty restrictive, more so than clipboard one.
> >>
> >> R.Sz.
> >>
> >
>
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVXa/gAAoJENuP0xzK19csvUEH/0169aCTtLJyZCSYAKtGmqAv
u6hO5vWf1i5Z/tU/KyuAuhW2Gv9CgzQvmhb1EtTKVcYv9xyT/axCK64eILgmjaau
RvLwNa8YnZaV/IUkyPW7V/1vgdyPF0QUscQBFDNnc/mJVegB6e8kpzq1HOXTULVW
V6qxVJHnE/uJwcgB23FyvLUgluIDRJATP0vIXmSOWpDIlQts49PyV60iKLIeTmoq
6gydzTFxQfXDNGkq/qrnbdzaOYuxIdoVeAnUNLhYy3F69O7m1O8PTRIC6LGftNwV
+jA1tzU7hpUCBtFX1IBoTQtOys4dw3sYQ0ftis+yqVT8Lbfe6Xgd1ykqOKxamgw=
=uR4q
-----END PGP SIGNATURE-----
Vít Šesták
May 21, 2015, 10:06:58 AM5/21/15
to qubes...@googlegroups.com, groups-no-private-mail--con...@v6ak.com
Hello,
Actually we use this feature/bug in some places - for example gpg
backend has name of calling VM bold. Also I'm not sure if this is a
feature or a bug.
Maybe there could be two services: Notify and NotifyHTML and you can
setup policy to allow the later one only for more trusted VMs?
Until I know what the HTML support is limited to, I don't want it. I've realized that some CSS works in KNotify, but position:absolute does not. What is allowed? JS? Privileged JS? Is there any possibility to spoof some UI, e.g. the AppVM name?
It is hard to be sure for a single notification daemon like KNotify. It is even harder is you consider more notification daemons (xfce4-notify, mate-notification-daemon, notify-osd, …). I am against HTML until we are sure.
It is hard to be sure for a single notification daemon like KNotify. It is even harder is you consider more notification daemons (xfce4-notify, mate-notification-daemon, notify-osd, …). I am against HTML until we are sure.
As you've guessed, I vote for Python :)
OK
Maybe just as now - 3 lines. But each encoded with base64? Of course
later it needs some sanitization:
- validate UTF-8
- filter/drop HTML tags and maybe some control characters
- some length limit
If we assume a HTML input, we should also somehow validate entities, at least briefly. Or maybe we should send a plaintext and just escape it in the Dom0, which is less error prone.
In https://github.com/QubesOS/qubes-issues/issues/889 Joanna suggests we should filter the strings the same way as it is done for window titles. This reminds me why I don't like the filtering. It is too strict. For example, “Vít Šesták” is transformed to “V__t __est__k”. And there are many other Unicode characters that are filtered out.
I'm not sure if this is good idea to have actions in this protocol.
Maybe if the application requests some actions, just handle such notify
locally?
Why not? Do you find it to be tricky and a potential place for some vulnerability?
Local notification handling seems to be hard for me. With libnotify, you can have only one notification daemon (one for proxying notifications and second for displaying notifications on local VM), so the easiest way to handle it locally would probably be creating a custom GUI for it.
Local notification handling seems to be hard for me. With libnotify, you can have only one notification daemon (one for proxying notifications and second for displaying notifications on local VM), so the easiest way to handle it locally would probably be creating a custom GUI for it.
There is already such image converter, take a look at
linux-utils/core/imgconverter.py (or
/usr/lib64/python2.7/site-packages/qubes/imgconverted.py in VM).
Thank you for pointing to the script.
Maybe we can just don't give any feedback to the calling VM? Just like
do not support actions. But I'm not sure if this is a big problem.
I don't think it is a big problem, but it is good to be aware of.
We can implement some per-VM rate-limit (like 20/min). But IMO we can
ignore the problem in first version.
I agree it is rather a minor issue.
Size surely needs to be limited. Does dbus notification API specify any
size limit? Maybe we can use the same?
The Dbus API specifies a 128MiB limit (see http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-messages ), which is huge. In https://developer.gnome.org/notification-spec/ , I've found only image dimensions upper limit, which is 200×100, which is about 60 000 bytes in RGB. For other fields, size over 1KiB in total probably does not make sense. This suggests that a size over 60KiB in total (including the icon) probably does not make sense.
Regards,
Vít Šesták 'v6ak'
Regards,
Vít Šesták 'v6ak'
Marek Marczykowski-Górecki
May 21, 2015, 11:33:07 AM5/21/15
to Vít Šesták, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hash: SHA1
On Thu, May 21, 2015 at 07:06:58AM -0700, Vít Šesták wrote:
> Hello,
>
>
> > Actually we use this feature/bug in some places - for example gpg
> > backend has name of calling VM bold. Also I'm not sure if this is a
> > feature or a bug.
> > Maybe there could be two services: Notify and NotifyHTML and you can
> > setup policy to allow the later one only for more trusted VMs?
> >
> Until I know what the HTML support is limited to, I don't want it. I've
> realized that some CSS works in KNotify, but position:absolute does not.
> What is allowed? JS? Privileged JS? Is there any possibility to spoof some
> UI, e.g. the AppVM name?
>
> It is hard to be sure for a single notification daemon like KNotify. It is
> even harder is you consider more notification daemons (xfce4-notify,
> mate-notification-daemon, notify-osd, …). I am against HTML until we are
> sure.
Ok, sounds reasonable.
> Hello,
>
>
> > Actually we use this feature/bug in some places - for example gpg
> > backend has name of calling VM bold. Also I'm not sure if this is a
> > feature or a bug.
> > Maybe there could be two services: Notify and NotifyHTML and you can
> > setup policy to allow the later one only for more trusted VMs?
> >
> Until I know what the HTML support is limited to, I don't want it. I've
> realized that some CSS works in KNotify, but position:absolute does not.
> What is allowed? JS? Privileged JS? Is there any possibility to spoof some
> UI, e.g. the AppVM name?
>
> It is hard to be sure for a single notification daemon like KNotify. It is
> even harder is you consider more notification daemons (xfce4-notify,
> mate-notification-daemon, notify-osd, …). I am against HTML until we are
> sure.
> As you've guessed, I vote for Python :)
> >
> OK
>
> Maybe just as now - 3 lines. But each encoded with base64? Of course
> > later it needs some sanitization:
> > - validate UTF-8
> > - filter/drop HTML tags and maybe some control characters
> > - some length limit
> >
>
> If we assume a HTML input, we should also somehow validate entities, at
> least briefly. Or maybe we should send a plaintext and just escape it in
> the Dom0, which is less error prone.
'<' or '>' if we do not allow HTML. If any "wrong" character is
detected, it should drop the whole notify message.
It should be VM agent responsibility to prepare the message to be
accepted - for example drop HTML tags etc.
> In https://github.com/QubesOS/qubes-issues/issues/889 Joanna suggests we
> should filter the strings the same way as it is done for window titles.
> This reminds me why I don't like the filtering. It is too strict. For
> example, “Vít Šesták” is transformed to “V__t __est__k”. And there are many
> other Unicode characters that are filtered out.
> > I'm not sure if this is good idea to have actions in this protocol.
> > Maybe if the application requests some actions, just handle such notify
> > locally?
> >
> Why not? Do you find it to be tricky and a potential place for some
> vulnerability?
action, which makes the whole service much more complicated. The same
applies to canceling the notification.
> Local notification handling seems to be hard for me. With libnotify, you
> can have only one notification daemon (one for proxying notifications and
> second for displaying notifications on local VM), so the easiest way to
> handle it locally would probably be creating a custom GUI for it.
> There is already such image converter, take a look at
> > linux-utils/core/imgconverter.py (or
> > /usr/lib64/python2.7/site-packages/qubes/imgconverted.py in VM).
> >
>
> Thank you for pointing to the script.
>
> Maybe we can just don't give any feedback to the calling VM? Just like
> > do not support actions. But I'm not sure if this is a big problem.
> >
> I don't think it is a big problem, but it is good to be aware of.
>
> We can implement some per-VM rate-limit (like 20/min). But IMO we can
> > ignore the problem in first version.
> >
> I agree it is rather a minor issue.
>
>
> > Size surely needs to be limited. Does dbus notification API specify any
> > size limit? Maybe we can use the same?
> >
> The Dbus API specifies a 128MiB limit (see
> http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-messages
> ), which is huge. In https://developer.gnome.org/notification-spec/ , I've
> found only image dimensions upper limit, which is 200×100, which is about
> 60 000 bytes in RGB. For other fields, size over 1KiB in total probably
> does not make sense. This suggests that a size over 60KiB in total
> (including the icon) probably does not make sense.
>
> Regards,
> Vít Šesták 'v6ak'
>
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVXfqrAAoJENuP0xzK19csNosH/1zmLro1zZ8euf8XMhjzVu6s
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
4OvfwcGb1Iy0B4YSC+chq0UCcuZLd2SeLUtT1a2Ti/KI+FNLOQG8FGD1IiMBSGJw
5u6seElHeBYtwusaWi0WlaK351NGkOYjdJM/ReADxNDcLLVC4BmkIwZEfp52wqjm
BeuVbOEzkI/f0xrZDG1E7dSdv3JO07tAQhqfPbzfpnEK7H3Q0urRftRcTVp+3717
DBT/rVfUSx4xjAKQD79pmseHxe2llcJpwFJ4HtodoCRKufZhnALGyfv0oVAibhr3
kzDTqZzr+DehKrs1SC+tuyhi/0I3e8JrZbzC9+bSkSYFXp4eM4DmMMkoixHj39s=
=vPZc
-----END PGP SIGNATURE-----
Vít Šesták
May 21, 2015, 4:08:57 PM5/21/15
to qubes...@googlegroups.com, groups-no-private-mail--con...@v6ak.com
I think dom0 should only validate the string - for example forbid any
'<' or '>' if we do not allow HTML. If any "wrong" character is
detected, it should drop the whole notify message.
It should be VM agent responsibility to prepare the message to be
accepted - for example drop HTML tags etc.
There is more that should be validated. HTML can also contain entities. One might try to perform some attack on HTML parser using malformed entities, e.g. long entity name, long &#code; entity, unclosed entity. I think that calling some search&replace function (which does just search&replace for '<', '&' and optionally for some other characters like '>', '"' and '\') is easier than validating entities.
This means you need some stateful protocol to be able to return selected
action, which makes the whole service much more complicated. The same
applies to canceling the notification.
I am new to Qubes RPC, but it seems to allow maintaining an interactive session. Moreover, if such actions can be directed to another process, one daemon could serve them all. It should not be so hard to implement it, I think. But this is rather nice-to-have.
Regards,
Vít Šesták 'v6ak'
Regards,
Vít Šesták 'v6ak'
Marek Marczykowski-Górecki
May 21, 2015, 4:46:18 PM5/21/15
to Vít Šesták, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hash: SHA1
On Thu, May 21, 2015 at 01:08:57PM -0700, Vít Šesták wrote:
>
>
> > I think dom0 should only validate the string - for example forbid any
> > '<' or '>' if we do not allow HTML. If any "wrong" character is
> > detected, it should drop the whole notify message.
> > It should be VM agent responsibility to prepare the message to be
> > accepted - for example drop HTML tags etc.
> >
> There is more that should be validated. HTML can also contain entities. One
> might try to perform some attack on HTML parser using malformed entities,
> e.g. long entity name, long &#code; entity, unclosed entity. I think that
> calling some search&replace function (which does just search&replace for
> '<', '&' and optionally for some other characters like '>', '"' and '\') is
> easier than validating entities.
Ok.
>
>
> > I think dom0 should only validate the string - for example forbid any
> > '<' or '>' if we do not allow HTML. If any "wrong" character is
> > detected, it should drop the whole notify message.
> > It should be VM agent responsibility to prepare the message to be
> > accepted - for example drop HTML tags etc.
> >
> There is more that should be validated. HTML can also contain entities. One
> might try to perform some attack on HTML parser using malformed entities,
> e.g. long entity name, long &#code; entity, unclosed entity. I think that
> calling some search&replace function (which does just search&replace for
> '<', '&' and optionally for some other characters like '>', '"' and '\') is
> easier than validating entities.
> This means you need some stateful protocol to be able to return selected
> > action, which makes the whole service much more complicated. The same
> > applies to canceling the notification.
> >
> I am new to Qubes RPC, but it seems to allow maintaining an interactive
> session. Moreover, if such actions can be directed to another process, one
> daemon could serve them all. It should not be so hard to implement it, I
> think. But this is rather nice-to-have.
>
> Regards,
> Vít Šesták 'v6ak'
>
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVXkQQAAoJENuP0xzK19csxsQH/1QjcEShXx286e9jzS8JZmIN
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
0ySV7mgJXnU3ACLLxuVfZ+NyxKKQv2jHVS8By+PQRle2wMDi8yHJ3rpf1ri6sqE5
UCe/i7xB4+ISGcFim40UEpOZGWGKRp2F9qX3NEGA3vIy6Iny0LR2IbkOd8AktAm4
lJcjR3jPE5luv2wG2JWg8vs06c8aYwPHujjaHxnusuthUeFoh5NMYN09pIuBafAu
Rn6BrUib1esTDpqpU8xneXJ9RFOwM5otQGDIEz9jKO3bqIBqiLBirPj5wnzNRpTT
IezYiYYW2rQ6Q17tp0uQYFQ1mydNce1S4wrd7UA/uXA06X0NKaFunRNoTouqN8s=
=B1HJ
-----END PGP SIGNATURE-----
Vít Šesták
Jul 29, 2015, 11:41:53 AM7/29/15
to qubes-devel, marm...@invisiblethingslab.com
Unfortunately, this is not my high priority. But I've found some security implication. When Unicode is allowed, the attacker might try to use some control characters in order toswitch the text direction from LTR to RTL. As a result, instead of showing “vmname: notification”, it would show “some arbitrary text :emanmv” or even “some arbitrary text …” if the message is too long. In other words, the VM would be able to spoof messages from other VMs, even from dom0.
I am not sure what the ideal mitigation is. The most simple one is forcing LTR text direction. This is obviously unfriendly for RTL users. One might try to handle all the strings is some way so that the RTL impact is limited only to the message itself.
BTW, this is an issue in Chrome's location bar, as it allows some spoofing… This was actually my inspiration for that: https://code.google.com/p/chromium/issues/detail?id=351639
Regards,
Vít Šesták 'v6ak'
I am not sure what the ideal mitigation is. The most simple one is forcing LTR text direction. This is obviously unfriendly for RTL users. One might try to handle all the strings is some way so that the RTL impact is limited only to the message itself.
BTW, this is an issue in Chrome's location bar, as it allows some spoofing… This was actually my inspiration for that: https://code.google.com/p/chromium/issues/detail?id=351639
Regards,
Vít Šesták 'v6ak'
Marek Marczykowski-Górecki
Jul 29, 2015, 6:16:53 PM7/29/15
to Vít Šesták, qubes-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Wed, Jul 29, 2015 at 08:41:52AM -0700, Vít Šesták wrote:
> Unfortunately, this is not my high priority. But I've found some security
> implication. When Unicode is allowed, the attacker might try to use some
> control characters in order toswitch the text direction from LTR to RTL. As
> a result, instead of showing “vmname: notification”, it would show “some
> arbitrary text :emanmv” or even “some arbitrary text …” if the message is
> too long. In other words, the VM would be able to spoof messages from other
> VMs, even from dom0.
>
> I am not sure what the ideal mitigation is. The most simple one is forcing
> LTR text direction. This is obviously unfriendly for RTL users. One might
> try to handle all the strings is some way so that the RTL impact is limited
> only to the message itself.
We use the second approach in window titles (at least in KDE) - the VM
name is simply a separate text area.
iQEcBAEBCAAGBQJVuVDPAAoJENuP0xzK19csPIoH/it1d9ZO2mAAoYTkrrsZtF0+
dUY9qapwX0OKB+Jw4oIvhZKujrPvn42Uv6bgXutOy8GIe5UI83w5KGkPFJoxHk1s
PJGFtIaQ+D+X+BDfkIK7vhC7Wyn7P5RjWM6vwWTBxDp6z/KG3xKmAp1iUJk1flTj
mPjYd0BYb16k2OuIBTgeUidQJr+KDO5XXOe0RVDspWAeT0ZvGY5yXsw6Z9TuBFuJ
/Vqu7XOMC/dfZJnQXyDh2XMFy6QxCEr3C6FUwzq2qDvROMJBZLN2WDJTB/gOR64i
3wzRwoG7dIcR5UpZUHnyLIoGkY6iOKHVjzv3ECkmE2cjfBk/DA2K3PRfh644ufM=
=1umt
-----END PGP SIGNATURE-----
Hash: SHA256
On Wed, Jul 29, 2015 at 08:41:52AM -0700, Vít Šesták wrote:
> Unfortunately, this is not my high priority. But I've found some security
> implication. When Unicode is allowed, the attacker might try to use some
> control characters in order toswitch the text direction from LTR to RTL. As
> a result, instead of showing “vmname: notification”, it would show “some
> arbitrary text :emanmv” or even “some arbitrary text …” if the message is
> too long. In other words, the VM would be able to spoof messages from other
> VMs, even from dom0.
>
> I am not sure what the ideal mitigation is. The most simple one is forcing
> LTR text direction. This is obviously unfriendly for RTL users. One might
> try to handle all the strings is some way so that the RTL impact is limited
> only to the message itself.
name is simply a separate text area.
dUY9qapwX0OKB+Jw4oIvhZKujrPvn42Uv6bgXutOy8GIe5UI83w5KGkPFJoxHk1s
PJGFtIaQ+D+X+BDfkIK7vhC7Wyn7P5RjWM6vwWTBxDp6z/KG3xKmAp1iUJk1flTj
mPjYd0BYb16k2OuIBTgeUidQJr+KDO5XXOe0RVDspWAeT0ZvGY5yXsw6Z9TuBFuJ
/Vqu7XOMC/dfZJnQXyDh2XMFy6QxCEr3C6FUwzq2qDvROMJBZLN2WDJTB/gOR64i
3wzRwoG7dIcR5UpZUHnyLIoGkY6iOKHVjzv3ECkmE2cjfBk/DA2K3PRfh644ufM=
=1umt
-----END PGP SIGNATURE-----
Reply all
Reply to author
Forward
0 new messages