Re: Checking for services to be restarted on a default Debian installation
On 7 September 2014 15:30:22 CEST, David Prévot taf...@debian.org wrote: Le 07/09/2014 02:07, Paul Wise a écrit : On Tue, Sep 2, 2014 at 2:48 AM, Thijs Kinkhorst wrote: My questions to this list: - Do people agree that this would be something that's good to have in a default installation? Are there drawbacks? Not restarting by default the DM seems to be nice thing to have. How does it work if the upgrade run in the background? Will all needed service be restarted without asking? (If so, the gdm3 restart issue may be a blocker). As a long time user and system administrator I agree that notification and *optional* automatic restarts have a place in the default install (with appropriate notes in the changelog for Jessie, obviously!). For a server, there should be some easy to adjust setting, choosing between automatic restarts and simply notifying of restart of x, y, z needed due to upgrade b and c (with comment from changelog: is this a security issue?). Do we have a framework for persistent gui notifications on the desktop? Eg: next time someone in the sudo group logs in; show request for system restart/kexec and/or subsystem restarts? I know Ubuntu has a default software center thing for that -- is there something like it in tasksel-desktop? (I generally run a lean xmonad-only setup - a notification in my xmobar would be nice, though) On a server I'm generally happy with an email to root - but do we have somewhere we could put notifications? Eg: service names in /var/run/restart-pending or something along those lines? The idea being that apt/dpgk/checkrestart could append package names here, and a do-pending-restarts-script could remove them (probably better just to run checkrestarts again and verify start time/loaded libraries vs latest installed version and update the needs-restart queue as appropriate?). The more I think about, the better I like the idea of having a text-file as a job queue of pending restarts, and a script that checks running processes for open dlls that updates such a file (can be put in cron for generatoøing gui alerts w fallback to console alerts on systems w/o xorg). Alerting for restarts amounts to checking for the presence of such a file and re-running the checkrestart script to regenerate it, or remove it if all needed restarts are done (seperate file for kernel, or use service name kexec? For servers it might nice to notify on updated inintrd/grub.cfg as there is no *guarantee* the system will boot after such changes -- until they've been verified by a successful reboot). Thoughts? Is this overboard for getting into Jessie? Best regards, Eirik -- Via phone - please excuse quoting and spelling -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/6ce482b6-9de9-4c7f-9c59-1178dc87d...@email.android.com
Re: concrete steps for improving apt downloading security and privacy
On 10 July 2014 18:07:59 CEST, Elmar Stellnberger estel...@gmail.com wrote: In order to prevent unsuspecting users from downloading a compromised version of Debian I wanna propose the following: * promote the inclusion of Debian-public-keys in any free live CD sold with magazines and books: I believe there is a copy of the key on the install cds? I don't see how getting a cd and a key from the same source really increases the trust level? A better approach might be having the magazines publish their own key/fingerprint in every issue and then manually (with a face-to-face meeting) have the magazines sign the Debian key (s) and upload the signatures to the keyerver network. (...) There is no sense in verifying a download with gpg unless you have fetched the public keys from a secure source. You should be very careful when using the term secure source of public keys. A key is considered secure of it is trusted; it is considered trusted if it is signed by someone (many!) you trust: eg yourself or someone you know (and have the trusted key of). Don't turn public crytography into secret key cryptography! Web-of-trust is a state of the art way to manage trust and key distribution! (...) * https mirrors could in addition provide some additional security including - more privacy about the selection of packages you have downloaded I think now, and for the forseeable future, many (most) mirrors are likely to be run by goverment sponsored/friendly institutions - and at any rate are likely to maintain traffic/access logs (in some jurisdictions this is mandated by law). Plain https does not protect (much) against a nation state level adversary. Onion transports and local mirroring seem a better option if the goal is privacy. Even then, knowing that someone runs Debian and dates and filesizes of security updates might be enough to guess at installed packages/open vulnerabilities in a system? - no deliberate delaying of new security updates (+ dnssec of course) See above re:traffic analysis. I do think cron-apt could use some love/a better alternative? - secure download of individual packages on a non Debian machine for transport to an offline Debian machine We already have this? - an additional security mechanism if some private keys should ever be stolen temporarily Keys cannot be stolen temporary; they are trusted or untrusted (revoked). Speaking off - we could perhaps have a better ui for adding/revoking keys? With better support for web of trust and key severs? the current certificate authorization process is heavily compromised !! Yes, I would also like to see a Debian CA set up - just because it would make sense to anchor trust of other ssl - infrastructure in the gpg-signed iso/dpkg distribution. As it is (as the ca certs are distributed the same as the rest of Debian) it only offers a secondary attack surface. You could be getting rogue ca certs the same way you could ne getting a backdoored libssl/kernel/etc. The one benefit of the CA system is that cacerts are distributed by other os vendors as well. I think that is where a lot of this type of discussion is comming from. People would rather go to a website that windos xp saus is safe, in order to get Debian - rather than make an effort to verify the trust of Debian's various gpg keys. Arguably we could do better with encouraging more user groups to do keysigning parties and education in order to make trust in gpg more easily viable for new users. As for pinning trust: one (not very rigorous) approach is to simpky assume you're not currently compromised (that is a necessary assumtion if you want to use gpg anyway) and sign the current Debian keys with your own gpg key (plaese do not upload such leap-of-faith signatures to the keyservers, though). When you've done that, either: 1) you've signed a compromised key: at least if you discover that later, you know how far back you were (at least) compromised. 2) You've trrusted a trustworthy key; you're safe until the next roll-over. We could perhaps do a better job saying some of the above on the wiki/homepage? It's unfortunately unreasonable to assume most users are familiar with gpg and trust networks. Comments? -eirik Ps: please trim and quote appropriately when posting to the list. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/d25f241b-aaa2-449e-a98b-d40d8e3d3...@email.android.com
