ZeroConf in Ubuntu

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/zeroconf-ubuntu.html

(Disclaimer: I am not an Ubuntu user myself. But I happen to be the lead developer of Avahi.)

It came to my attention that Ubuntu is
discussing
whether
to
enable Zeroconf/Avahi in default installations. I would like to point out a few
things:

The “No Open Ports” policy: This policy (or at least the
way many people interprete it) seems to be thought out by someone who
doesn’t have much experience with TCP/IP networking. While it might make sense
to enforce this for application-level protocols like HTTP or FTP it doesn’t
make sense to apply it to transport-level protocols such as DHCP, DNS or in
this case mDNS (the underlying protocol of Zeroconf/Avahi/Bonjour):

  • Even the simplest DNS lookup requires the opening of an UDP port for a
    short period of time to be able to recieve the response. This is usually not
    visible to the administrator, because the time is too short to show up in
    netstat -uln, but nonetheless it is an open port. (UDP is not
    session-based (like TCP is) so incoming packets are accepted regardless where
    they come from)
  • DHCP clients listen on UDP port 68 during their entire lifetime (which in
    most cases is the same as the uptime of the machine). DHCP may be misused for
    much worse things than mDNS. Evildoers can forge DHCP packets to change IP
    addresses and routing of machines. This is definitely something that cannot be
    done with mDNS.

All three protocols, DNS, DHCP and mDNS, require a little bit of trust in
the local LAN. They (usually) don’t come with any sort of authentication and
they all are very easy to forge. The impact of forged mDNS packets is clearly
less dangerous than forged DHCP or DNS packets. Why? Because mDNS doesn’t
allow you to change the IP address or routing setup (which forged DHCP allows)
and because it cannot be used to spoof host names outside the .local
domain (which forged DNS allows).

Enforcing the “No Open ports” policy everywhere in Ubuntu would require that
both DNS and DHCP are disabled by default. However, as everybody probably
agrees, this would be ridiculous because a standard Ubuntu installation
couldn’t even be used for the most basic things like web browsing.

Oh, and BTW: DNS lookups are usually done by an NSS plugin which is loaded
by the libc into every process which uses gethostbyname() (the function for doing host name resolutions). So, in
effect every single process that uses this function has an open port for a
short time. And the DNS client code runs with user priviliges, so an exploit
really hurts. dhclient (the DHCP client) runs as root during the entire
runtime, so an exploit of it hurts even more. Avahi in contrast runs as its own user and
chroot()s
.

It is not my intention to force anyone to use my
software
. However, enforcing the “No Open Ports” policy unconditionally is
not a good idea. Currently Ubuntu makes exceptions for DHCP/DNS and so
it should for mDNS.

I do agree that publishing all kinds of local services with Avahi in a
default install is indeed problematic. However, if the “No Open Ports” policy
is enforced on all other application-level software, there shouldn’t be any
application that would want to register a service with Avahi.

Starting Avahi “on-demand” is not an option either, because it offers useful
services even when no local application is accessing is. Most notably this is
host name resolution for the local host name. (Hey, yeah, Zeroconf is more than
just stealing music.)

Remember: Zeroconf is about
Zero Configuration. Requiring the user to toggle some obscure
configuration option before he can use Zeroconf would make it a paradox.
Zeroconf was designed to make things “just work”. If it isn’t enabled by
default it is impossible to reach that goal.

Oh, and I enabled commmenting in my blog, if anyone wants to flame me on this…

ZeroConf in Ubuntu

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/zeroconf-ubuntu.html

(Disclaimer: I am not an Ubuntu user myself. But I happen to be the lead developer of Avahi.)

It came to my attention that Ubuntu is
discussing
whether
to
enable Zeroconf/Avahi in default installations. I would like to point out a few
things:

The “No Open Ports” policy: This policy (or at least the
way many people interprete it) seems to be thought out by someone who
doesn’t have much experience with TCP/IP networking. While it might make sense
to enforce this for application-level protocols like HTTP or FTP it doesn’t
make sense to apply it to transport-level protocols such as DHCP, DNS or in
this case mDNS (the underlying protocol of Zeroconf/Avahi/Bonjour):

  • Even the simplest DNS lookup requires the opening of an UDP port for a
    short period of time to be able to recieve the response. This is usually not
    visible to the administrator, because the time is too short to show up in
    netstat -uln, but nonetheless it is an open port. (UDP is not
    session-based (like TCP is) so incoming packets are accepted regardless where
    they come from)
  • DHCP clients listen on UDP port 68 during their entire lifetime (which in
    most cases is the same as the uptime of the machine). DHCP may be misused for
    much worse things than mDNS. Evildoers can forge DHCP packets to change IP
    addresses and routing of machines. This is definitely something that cannot be
    done with mDNS.

All three protocols, DNS, DHCP and mDNS, require a little bit of trust in
the local LAN. They (usually) don’t come with any sort of authentication and
they all are very easy to forge. The impact of forged mDNS packets is clearly
less dangerous than forged DHCP or DNS packets. Why? Because mDNS doesn’t
allow you to change the IP address or routing setup (which forged DHCP allows)
and because it cannot be used to spoof host names outside the .local
domain (which forged DNS allows).

Enforcing the “No Open ports” policy everywhere in Ubuntu would require that
both DNS and DHCP are disabled by default. However, as everybody probably
agrees, this would be ridiculous because a standard Ubuntu installation
couldn’t even be used for the most basic things like web browsing.

Oh, and BTW: DNS lookups are usually done by an NSS plugin which is loaded
by the libc into every process which uses gethostbyname() (the function for doing host name resolutions). So, in
effect every single process that uses this function has an open port for a
short time. And the DNS client code runs with user priviliges, so an exploit
really hurts. dhclient (the DHCP client) runs as root during the entire
runtime, so an exploit of it hurts even more. Avahi in contrast runs as its own user and
chroot()s
.

It is not my intention to force anyone to use my
software
. However, enforcing the “No Open Ports” policy unconditionally is
not a good idea. Currently Ubuntu makes exceptions for DHCP/DNS and so
it should for mDNS.

I do agree that publishing all kinds of local services with Avahi in a
default install is indeed problematic. However, if the “No Open Ports” policy
is enforced on all other application-level software, there shouldn’t be any
application that would want to register a service with Avahi.

Starting Avahi “on-demand” is not an option either, because it offers useful
services even when no local application is accessing is. Most notably this is
host name resolution for the local host name. (Hey, yeah, Zeroconf is more than
just stealing music.)

Remember: Zeroconf is about
Zero Configuration. Requiring the user to toggle some obscure
configuration option before he can use Zeroconf would make it a paradox.
Zeroconf was designed to make things “just work”. If it isn’t enabled by
default it is impossible to reach that goal.

Oh, and I enabled commmenting in my blog, if anyone wants to flame me on this…

Announcing SECCURE

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/seccure.html

Yesterday my brother released his second Free Software package, the SECCURE Elliptic Curve Crypto Utility for Reliable Encryption. (Recursive acronyms, yay!)

The seccure toolset implements a selection of asymmetric algorithms based on elliptic curve cryptography (ECC). In particular, it offers public key encryption / decryption and signature generation / verification. ECC schemes offer a much better key size to security ratio than classical systems (RSA, DSA). Keys are short enough to make direct specification of keys on the command line possible (sometimes this is more convenient than the management of PGP-like key rings). seccure builds on this feature and therefore is the tool of choice whenever lightweight asymmetric cryptography — independent of key servers, revocation certificates, the Web of Trust, or even configuration files — is required.

Anyone willing to work on the Debian RFP?

(The first Free Software package of him is ssss, an implementation of Shamir’s secret sharing scheme)

Announcing SECCURE

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/seccure.html

Yesterday my brother released his second Free Software package, the SECCURE Elliptic Curve Crypto Utility for Reliable Encryption. (Recursive acronyms, yay!)

The seccure toolset implements a selection of asymmetric algorithms based on elliptic curve cryptography (ECC). In particular, it offers public key encryption / decryption and signature generation / verification. ECC schemes offer a much better key size to security ratio than classical systems (RSA, DSA). Keys are short enough to make direct specification of keys on the command line possible (sometimes this is more convenient than the management of PGP-like key rings). seccure builds on this feature and therefore is the tool of choice whenever lightweight asymmetric cryptography — independent of key servers, revocation certificates, the Web of Trust, or even configuration files — is required.

Anyone willing to work on the Debian RFP?

(The first Free Software package of him is ssss, an implementation of Shamir’s secret sharing scheme)

Announcing SECCURE

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/seccure.html

Yesterday my brother released his second Free Software package, the SECCURE Elliptic Curve Crypto Utility for Reliable Encryption. (Recursive acronyms, yay!)

The seccure toolset implements a selection of asymmetric algorithms based on elliptic curve cryptography (ECC). In particular, it offers public key encryption / decryption and signature generation / verification. ECC schemes offer a much better key size to security ratio than classical systems (RSA, DSA). Keys are short enough to make direct specification of keys on the command line possible (sometimes this is more convenient than the management of PGP-like key rings). seccure builds on this feature and therefore is the tool of choice whenever lightweight asymmetric cryptography — independent of key servers, revocation certificates, the Web of Trust, or even configuration files — is required.

Anyone willing to work on the Debian RFP?

(The first Free Software package of him is ssss, an implementation of Shamir’s secret sharing scheme)

GUADEC Sound BOF Slides

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/pulse-slides.html

Marc-Andre was so kind to upload the improvised mini-slides we had prepared for GUADEC’s sound BOF. Unfortunately there is no recording of the BOF, so this is all we can offer for those interested but who were not able to attend GUADEC.

In related news: Thanks to jat there is now a native PulseAudio driver for MPD (in SVN), and I updated the MPlayer patch, which adds a native PulseAudio driver to MPlayer.

GUADEC Sound BOF Slides

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/pulse-slides.html

Marc-Andre was so kind to upload the improvised mini-slides we had prepared for GUADEC’s sound BOF. Unfortunately there is no recording of the BOF, so this is all we can offer for those interested but who were not able to attend GUADEC.

In related news: Thanks to jat there is now a native PulseAudio driver for MPD (in SVN), and I updated the MPlayer patch, which adds a native PulseAudio driver to MPlayer.

GUADEC Sound BOF Slides

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/pulse-slides.html

Marc-Andre was so kind to upload the improvised mini-slides we had prepared for GUADEC’s sound BOF. Unfortunately there is no recording of the BOF, so this is all we can offer for those interested but who were not able to attend GUADEC.

In related news: Thanks to jat there is now a native PulseAudio driver for MPD (in SVN), and I updated the MPlayer patch, which adds a native PulseAudio driver to MPlayer.

Re: PulseAudio and GNOME

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/pulse-davidz-reply.html

davidz: Shams King is
currently working on HAL support in PulseAudio. He’s planning to extend
our module-combine
to automatically combine all available hardware sound cards found with
HAL into a single virtual sound sink. That way, if the user plugs in
an USB loudspeaker set it will automatically output the same audio as
the internal speakers did before. I believe this is the behaviour most
non-technical users would expect from a well designed system.

Right now PulseAudio sink names cannot be used to identify the
underlying hardware devices, since they are generic names like
alsa_output or oss_output2. However, it might be a
good idea to use the ALSA device name
(i.e. alsa_output_hw_0_0) or even the HAL identifier if it is
available. If this
dialog
uses the normal GStreamer PropertyProbe API to
query the available devices (and does not use HAL directly), we should
be able to support this easily in gst-pulse
(right now we support this interface in GstPulseMixer, but not yet in
GstPulseSink).

Marc-Andre, I wonder how the differentiation between “Sound events”, “Music and
Movies” and “Audio/Video Conferencing” touches the “role”/”class” model of GSmartMix?

Regarding power saving and PulseAudio: First of all, PulseAudio
right now is intended to be run per-session, just like esd
was. However, there is some incomplete support for running it as
system-wide instance.

I think instead of integrating PulseAudio with
gnome-power-manager the way you described it is probably a better idea
to close the sound device when it is idle regardless if we are in
power saving mode or not, and hope that the driver authors fix their
stuff to not produce any click or pop sounds when the device is opened
or closed. To be honest, all driver/sound card combinations I have
access to work properly in this area.

In ALSA you usually open devices in O_RDONLY or O_WRONLY mode (and not
in O_RDWR) anyway, so falling back to it is not really necessary.

Re: PulseAudio and GNOME

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/pulse-davidz-reply.html

davidz: Shams King is
currently working on HAL support in PulseAudio. He’s planning to extend
our module-combine
to automatically combine all available hardware sound cards found with
HAL into a single virtual sound sink. That way, if the user plugs in
an USB loudspeaker set it will automatically output the same audio as
the internal speakers did before. I believe this is the behaviour most
non-technical users would expect from a well designed system.

Right now PulseAudio sink names cannot be used to identify the
underlying hardware devices, since they are generic names like
alsa_output or oss_output2. However, it might be a
good idea to use the ALSA device name
(i.e. alsa_output_hw_0_0) or even the HAL identifier if it is
available. If this
dialog
uses the normal GStreamer PropertyProbe API to
query the available devices (and does not use HAL directly), we should
be able to support this easily in gst-pulse
(right now we support this interface in GstPulseMixer, but not yet in
GstPulseSink).

Marc-Andre, I wonder how the differentiation between “Sound events”, “Music and
Movies” and “Audio/Video Conferencing” touches the “role”/”class” model of GSmartMix?

Regarding power saving and PulseAudio: First of all, PulseAudio
right now is intended to be run per-session, just like esd
was. However, there is some incomplete support for running it as
system-wide instance.

I think instead of integrating PulseAudio with
gnome-power-manager the way you described it is probably a better idea
to close the sound device when it is idle regardless if we are in
power saving mode or not, and hope that the driver authors fix their
stuff to not produce any click or pop sounds when the device is opened
or closed. To be honest, all driver/sound card combinations I have
access to work properly in this area.

In ALSA you usually open devices in O_RDONLY or O_WRONLY mode (and not
in O_RDWR) anyway, so falling back to it is not really necessary.

Re: PulseAudio and GNOME

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/projects/pulse-davidz-reply.html

davidz: Shams King is
currently working on HAL support in PulseAudio. He’s planning to extend
our module-combine
to automatically combine all available hardware sound cards found with
HAL into a single virtual sound sink. That way, if the user plugs in
an USB loudspeaker set it will automatically output the same audio as
the internal speakers did before. I believe this is the behaviour most
non-technical users would expect from a well designed system.

Right now PulseAudio sink names cannot be used to identify the
underlying hardware devices, since they are generic names like
alsa_output or oss_output2. However, it might be a
good idea to use the ALSA device name
(i.e. alsa_output_hw_0_0) or even the HAL identifier if it is
available. If this
dialog
uses the normal GStreamer PropertyProbe API to
query the available devices (and does not use HAL directly), we should
be able to support this easily in gst-pulse
(right now we support this interface in GstPulseMixer, but not yet in
GstPulseSink).

Marc-Andre, I wonder how the differentiation between “Sound events”, “Music and
Movies” and “Audio/Video Conferencing” touches the “role”/”class” model of GSmartMix?

Regarding power saving and PulseAudio: First of all, PulseAudio
right now is intended to be run per-session, just like esd
was. However, there is some incomplete support for running it as
system-wide instance.

I think instead of integrating PulseAudio with
gnome-power-manager the way you described it is probably a better idea
to close the sound device when it is idle regardless if we are in
power saving mode or not, and hope that the driver authors fix their
stuff to not produce any click or pop sounds when the device is opened
or closed. To be honest, all driver/sound card combinations I have
access to work properly in this area.

In ALSA you usually open devices in O_RDONLY or O_WRONLY mode (and not
in O_RDWR) anyway, so falling back to it is not really necessary.

Photos from Vilanova/Barcelona

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/photos/barcelona.html

I finally found the time to sort my photos from Vilanova i la Geltrú and Barcelona.

My Windows of Barcelona series:

Windows of Barcelona

A few other nice shots:

Photo #361
Photo #371
Photo #366
Photo #381
Photo #386

Photo #222
Photo #210
Photo #125
Photo #137
Photo #5

Photo #311
Photo #301
Photo #317
Photo #281
Photo #269

Photo #268
Photo #89
Photo #49
Photo #35
Photo #95

These are:
1st row: Casa Milà; dito; dito; dito; dito;
2nd row: Palau de la Música Catalana; dito; Mies van der Rohe Pavilion; dito; Vilanova Lighthouse;
3rd row: Sagrada Família; dito; dito; Hospital de Sant Pau; dito;
4th row: Sagrada Família, seen from Sant Pau; City Center/Barri Gòtic; dito; dito; Plaça Reial

A panoramic view of Barcelona photographed from the Montjuic towards the north:

Barcelona Panorama

Those “thunderclouds” on the right side of the image are actually a
result of not using the same exposure settings on all photos that are
part of the panorama. Which is a mistake I didn’t repeat with my
second panoramic view, which again shows Barcelona from the Montjuic, but this time towards the east:

Barcelona Panorama 2

Dont miss the the entire album!

Photos from Vilanova/Barcelona

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/photos/barcelona.html

I finally found the time to sort my photos from Vilanova i la Geltrú and Barcelona.

My Windows of Barcelona series:

Windows of Barcelona

A few other nice shots:

Photo #361
Photo #371
Photo #366
Photo #381
Photo #386

Photo #222
Photo #210
Photo #125
Photo #137
Photo #5

Photo #311
Photo #301
Photo #317
Photo #281
Photo #269

Photo #268
Photo #89
Photo #49
Photo #35
Photo #95

These are:
1st row: Casa Milà; dito; dito; dito; dito;
2nd row: Palau de la Música Catalana; dito; Mies van der Rohe Pavilion; dito; Vilanova Lighthouse;
3rd row: Sagrada Família; dito; dito; Hospital de Sant Pau; dito;
4th row: Sagrada Família, seen from Sant Pau; City Center/Barri Gòtic; dito; dito; Plaça Reial

A panoramic view of Barcelona photographed from the Montjuic towards the north:

Barcelona Panorama

Those “thunderclouds” on the right side of the image are actually a
result of not using the same exposure settings on all photos that are
part of the panorama. Which is a mistake I didn’t repeat with my
second panoramic view, which again shows Barcelona from the Montjuic, but this time towards the east:

Barcelona Panorama 2

Dont miss the the entire album!

Photos from Vilanova/Barcelona

Post Syndicated from Lennart Poettering original http://0pointer.net/blog/photos/barcelona.html

I finally found the time to sort my photos from Vilanova i la Geltrú and Barcelona.

My Windows of Barcelona series:

Windows of Barcelona

A few other nice shots:

Photo #361
Photo #371
Photo #366
Photo #381
Photo #386

Photo #222
Photo #210
Photo #125
Photo #137
Photo #5

Photo #311
Photo #301
Photo #317
Photo #281
Photo #269

Photo #268
Photo #89
Photo #49
Photo #35
Photo #95

These are:
1st row: Casa Milà; dito; dito; dito; dito;
2nd row: Palau de la Música Catalana; dito; Mies van der Rohe Pavilion; dito; Vilanova Lighthouse;
3rd row: Sagrada Família; dito; dito; Hospital de Sant Pau; dito;
4th row: Sagrada Família, seen from Sant Pau; City Center/Barri Gòtic; dito; dito; Plaça Reial

A panoramic view of Barcelona photographed from the Montjuic towards the north:

Barcelona Panorama

Those “thunderclouds” on the right side of the image are actually a
result of not using the same exposure settings on all photos that are
part of the panorama. Which is a mistake I didn’t repeat with my
second panoramic view, which again shows Barcelona from the Montjuic, but this time towards the east:

Barcelona Panorama 2

Dont miss the the entire album!

The collective thoughts of the interwebz

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close