3 ms·

While this link is the expected joke, it is not joke at all. I'm writing software updater right now. Security is one of major concerns. Target platform, both c

by adontz 10y ago

While this link is the expected joke, it is not joke at all. I'm writing software updater right now. Security is one of major concerns. Target platform, both client and server side is Linux. I write most of the code in Python. Looks like great opportunity to use TUF. But it is not. My updater has so many specific requirements that TUF is not nearly what I need. More than this, TUF is not subset of what I need and cannot be foundation for what I need, even from security perspective.

bennofs 10y ago
Can you share what your different requirements that are not supported by TUF are?
- adontz 10y ago
  Software is split into a few overlays. Each overlay is filesystem slice, some overlays may have intersection. They are merged in specific order to get the final filesystem. Some overlays may be version-related (v1, v2), some environment-related (test, live), some may contain specific device configuration. Ordered overlay set forms an update stream. (That's just terminology we use, I do not want to teach somebody how to call things right) Initially client knows only own hardware ID (which is just sha256 of part serials, MAC, etc.), and registers itself on server, which is allowed only from trusted networks. During registration client receives unique HTTP client certificate. Later administrator approves registration and assigns client specific stream. Stream may include sensitive information, like unique credentials to access some other services. Some overlays, which are not secret, like executables, 3rd party libraries, OSS stuff, are just rsynced to save time and bandwidth, but others like configuration and credentials, are downloaded over HTTP with client certificate authentication. Overlays are merged on client side in memory and applied in semi-atomic way (series of file moves within partition, not writes or other I/O in between). There are a few other requirements, like log if devices tries to register second time, log if device tries to register from non-trusted network, log every update attempt, successful or failed, etc. And this is of course just brief overview. For instance, administrator approving registration is not a single person, but group of administrators, each with different permissions on streams. Client cannot download stream of some other client, and cannot get any information on overlays used by other clients, etc. I do not see any way generic updater [framework] (not only TUF) to fulfill my requirements not causing more problem, than solved.
  - evancordell 10y ago
    Most of what you describe is external to TUF (authenticating, logging, the specifics of the data you're protecting and how you transfer it once it's validated). A couple things you pointed out are definitely hard with TUF right now: > For instance, administrator approving registration is not a single person, but group of administrators, each with different permissions on streams TUF is being actively developed and this type of approval pattern is planned: https://github.com/theupdateframework/tuf/issues/346 https://github.com/theupdateframework/tuf/issues/346 > Client cannot download stream of some other client, and cannot get any information on overlays used by other clients, etc. This is currently a limitation of TUF, but it is known and there are some tentative plans to address it. If you have specific use cases you'd like to contribute to the discussion, there are GitHub issues and the mailing list. I think it's worth pointing out that even if you don't use TUF, you need to be thinking about the vulnerabilities it's designed to protect against. Once you start doing that you'll probably end up with something similar modulo formats and transport.
  - cel1ne 10y ago
    Complete shot into the blue, but could nix [0] provide something that you need? [0] https://nixos.org/nix/ https://nixos.org/nix/
joeblau 10y ago
Yeah, we're in a similar boat. We're writing a custom updater and a lot of the security aspect of what we need is already taken care of by our framework but we can't just whole-sale use TUF. I'm definitely starting and checking out this document for guidelines because we've already seen some issues that I'm sure other people who write updaters have figured out the optimal way to solve.

by adontz 10y ago

bennofs 10y ago

Can you share what your different requirements that are not supported by TUF are?

adontz 10y ago
Software is split into a few overlays. Each overlay is filesystem slice, some overlays may have intersection. They are merged in specific order to get the final filesystem. Some overlays may be version-related (v1, v2), some environment-related (test, live), some may contain specific device configuration. Ordered overlay set forms an update stream. (That's just terminology we use, I do not want to teach somebody how to call things right) Initially client knows only own hardware ID (which is just sha256 of part serials, MAC, etc.), and registers itself on server, which is allowed only from trusted networks. During registration client receives unique HTTP client certificate. Later administrator approves registration and assigns client specific stream. Stream may include sensitive information, like unique credentials to access some other services. Some overlays, which are not secret, like executables, 3rd party libraries, OSS stuff, are just rsynced to save time and bandwidth, but others like configuration and credentials, are downloaded over HTTP with client certificate authentication. Overlays are merged on client side in memory and applied in semi-atomic way (series of file moves within partition, not writes or other I/O in between). There are a few other requirements, like log if devices tries to register second time, log if device tries to register from non-trusted network, log every update attempt, successful or failed, etc. And this is of course just brief overview. For instance, administrator approving registration is not a single person, but group of administrators, each with different permissions on streams. Client cannot download stream of some other client, and cannot get any information on overlays used by other clients, etc. I do not see any way generic updater [framework] (not only TUF) to fulfill my requirements not causing more problem, than solved.
- evancordell 10y ago
  Most of what you describe is external to TUF (authenticating, logging, the specifics of the data you're protecting and how you transfer it once it's validated). A couple things you pointed out are definitely hard with TUF right now: > For instance, administrator approving registration is not a single person, but group of administrators, each with different permissions on streams TUF is being actively developed and this type of approval pattern is planned: https://github.com/theupdateframework/tuf/issues/346 https://github.com/theupdateframework/tuf/issues/346 > Client cannot download stream of some other client, and cannot get any information on overlays used by other clients, etc. This is currently a limitation of TUF, but it is known and there are some tentative plans to address it. If you have specific use cases you'd like to contribute to the discussion, there are GitHub issues and the mailing list. I think it's worth pointing out that even if you don't use TUF, you need to be thinking about the vulnerabilities it's designed to protect against. Once you start doing that you'll probably end up with something similar modulo formats and transport.
- cel1ne 10y ago
  Complete shot into the blue, but could nix [0] provide something that you need? [0] https://nixos.org/nix/ https://nixos.org/nix/

joeblau 10y ago

Yeah, we're in a similar boat. We're writing a custom updater and a lot of the security aspect of what we need is already taken care of by our framework but we can't just whole-sale use TUF. I'm definitely starting and checking out this document for guidelines because we've already seen some issues that I'm sure other people who write updaters have figured out the optimal way to solve.