Re: package for security advice
Russell Coker: > I think it would be good to have a package for improving system security. https://github.com/Whonix/security-misc > It > could depend on packages like spectre-meltdown-checker and also contain > scripts that look for ways of improving system security. For example > recommend SE Linux or Apparmor (if you don't have one installed), recommend > lockdown=confidentiality if using kernel 5.4 or greater, and do other similar > checks and warnings. Maybe you're looking for a hardened by default Debian derivative? https://www.whonix.org/wiki/Kicksecure > For each issue there would ideally be a URL provided > (maybe to the Debian Wiki, maybe to somewhere else) that describes the issue. https://www.whonix.org/wiki/System_Hardening_Checklist > I'm not saying that everyone should use all these features, just that > everyone > who cares about security should know what the options are and have made an > informed choice that they can easily review. > > For subsystems that are complex and security critical (like Apache and Samba > for example) you could have other packages providing check scripts that look > for common configuration choices that might reduce security. Such scripts > would be designed to give false positives rather than false negatives. The > idea being that if you do something potentially risky then you should be > aware > of it and so should whoever takes over your job in a few years time. Then at > relevant times (EG after an upgrade to a new release of Debian) decisions > about security can be reviewed. > > What do you think about this idea? The Problem with Security Guides and How We Can Fix It https://forums.whonix.org/t/the-problem-with-security-guides-and-how-we-can-fix-it/8563
Re: debcheckroot v2.0 released
Elmar Stellnberger: >>> Things debcheckroot does not check at the moment are the initrd and >> the MBR (master boot record). You may unpack the initrd by hand and >> check the files contained there against a sha256sum list generated by >> debcheckroot. The MBR can first be backuped by confinedrv/diskutils. >> Then reinstall it with Grub from a fresh boot CD and look if the boot >> sector has altered. Under normal circumstances Grub would install the >> exactly same code into the MBR. >> >> >> I guess "nobody" is going to do that. Sounds complicated. And I am > > The issue is that you do not need to check the initrd in deed under > normal circumstances. If the initrd is infected so will be > /sbin/mkinitramfs. Not necessarily. There are a lot more options to write a malicious initrd other than infecting /sbin/mkinitramfs. A rootkit could re-mount the real /sbin/mkinitramfs to a compromised hidden file /sbin/mkinitramfs, use LD_PRELOAD tricks and probably much more. > I have never seen the initrd being infected alone as > this would need to be updated on every new kernel configuration update > like when you install firmware. How often did you see initrd being infected? >> I would also suggest a different design / additional feature. Rather >> than requiring a network connection or DVD, could you add a feature >> please similar to "apt-file" or "command-not-found"? What I mean by that: >> >> These tools download a cache while the system is running. debcheckroot >> could download/generate/prepare all the sha256 files on the disk. Yes, >> within the running system. Don't worry about verifying integrity of >> these files just yet. That will be answered later. Yes, these sha256 >> files could be maliciously altered. But that is something you can check >> later at debcheckroot runtime. > > What you suggest here does not make sense to me. If you have to check > these sha256 lists later on it is the same work as if you do > not use them. Later on you don't have to re-generate the sha256 lists. Just verify their signatures. >> Generating the (sha256) files required for later verification could be >> done using an apt or dpkg hook. > > No, it is a feature of the tool that it does not require the dpkg > infrastructure. - an important one. I have even successfully verified an > old Debian6 installation with debcheckroot-v2.0. - no binaries required, > only plain Python available almost everywhere. Not using apt/dpkg comes at the expense of not being able to fully verify the whole system. What if there are outdated packages on the system which aren't available from anymore from repository? Using snapshot.debian.org? Also, for quickly repeatable verification it would be best to prepare as much as possible in background / during upgrade. Other tasks can be done at the same time. Then booting from read-only to debcheckroot purposes could safe a lot time. The less time it needs, the more it gets within reach to automate the process without sacrificing much boot time. Also by not using apt/dpkg, any packages downloaded would have to be gpg verified manually. I also don't see debcheckroot make use of gpg signature verification of downloaded files? Reinventing apt is difficult. See these attack on package managers: https://www2.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html Package metadata could be outdated. Downloaded package contents could be malicious or altered to pass verification. >> Then, later when debcheckroot runs, it would rely on these files. But to >> check that these files haven't been altered, it could check them against >> repository signing keys. So debcheckroot would need a bit root of trust >> built-in or better configurable. For example, it could be sufficient to >> point debcheckroot at clean Debian repository signing keys. These would >> then be used to check the sha256 files. > > Key signatures are not trustworthy in general. I have argued this a 100 > times; see also https://www.elstel.org/software/GnuPG-usage.html.en That article https://www.elstel.org/software/GnuPG-usage.html.en starts with "How to use GnuPG securely". That isn't the best way to communicate "Key signatures are not trustworthy in general" which is a pretty broad claim. If "Key signatures are not trustworthy in general" then all apt package downloads could be considered compromised since APT relies on gnupg for verification. With that was true, and with mindset, and that being unfixable, we could as well as give up. >> To a rootkit hunter which laymen can use it's a long way to go. Some > > debcheckroot is targeted at technically experienced users. That's sad. Understood. > No way to > hunt rootkits authored by the NSA otherwise. Yes, forget about NSA and alike. Let's not assume quasi-omnipotent attackers. That leads to defeatist mindset which isn't productive. > Well you can of course also use it for other > kinds of rootkits by other governments or from criminals but >
Re: debcheckroot v2.0 released
Anyone using this yet? I would speculate, not many are using it. It needs step by step instructions. Otherwise, most users are lost at hello. > Things debcheckroot does not check at the moment are the initrd and the MBR (master boot record). You may unpack the initrd by hand and check the files contained there against a sha256sum list generated by debcheckroot. The MBR can first be backuped by confinedrv/diskutils. Then reinstall it with Grub from a fresh boot CD and look if the boot sector has altered. Under normal circumstances Grub would install the exactly same code into the MBR. I guess "nobody" is going to do that. Sounds complicated. And I am saying that as a fairly technical user. (Maintaining Debian derivative distributions...) Users need very detailed step-by-step instructions. This is my experience from over 7 years of Whonix user support. Murphy's law. Anything can go wrong, will go wrong. Keep it simple stupid (KISS). Some stuff on usability: Quote To Toggle, or not to Toggle: The End of Torbutton https://blog.torproject.org/blog/toggle-or-not-toggle-end-torbutton > mike, am i completely anonymized if i log onto my facebook account? im using firefox 3.6 with tor and no script on windows 7 machine. thank you. Quote https://www.bbc.com/news/technology-20445632 > In order to make sure the mobile phone frequencies are not being tracked, I would fill up a washbasin with water and put the lid of a rice cooker over my head while I made a phone call," said one interviewee, a 28-year-old man who left the country in November 2010. [tor-dev] First-time tails/tor user feedback https://lists.torproject.org/pipermail/tor-dev/2012-April/003472.html Eliminating Stop-Points in the Installation and Use ofAnonymity Systems: a Usability Evaluation of the Tor Browser Bundle https://petsymposium.org/2012/papers/hotpets12-1-usability.pdf I would also suggest a different design / additional feature. Rather than requiring a network connection or DVD, could you add a feature please similar to "apt-file" or "command-not-found"? What I mean by that: These tools download a cache while the system is running. debcheckroot could download/generate/prepare all the sha256 files on the disk. Yes, within the running system. Don't worry about verifying integrity of these files just yet. That will be answered later. Yes, these sha256 files could be maliciously altered. But that is something you can check later at debcheckroot runtime. Generating the (sha256) files required for later verification could be done using an apt or dpkg hook. Then, later when debcheckroot runs, it would rely on these files. But to check that these files haven't been altered, it could check them against repository signing keys. So debcheckroot would need a bit root of trust built-in or better configurable. For example, it could be sufficient to point debcheckroot at clean Debian repository signing keys. These would then be used to check the sha256 files. The advantage of this would be that debcheckroot can be run from Live USD or Live DVD. Offline. No need for a network connection since all files to be verified would already be prepared. debcheckroot could be a Debian package that gets installed in the running system. And then starts preparing the sha256 files for later verification. It could also run the verification within the running system. That would just be an integrity check and no rootkit hunt. Since a system that is already running could be infected with a rootkit already. (Similar to debsums.) The same debcheckroot package then could also be used started from a Live USD or Live DVD and then "just" change the root (local of what debcheckroot should check) from the boot medium to the internal hard drive. debcheckroot could then verify that the existing sha256 files on the disk have valid signatures and if so, start the verification of all individual files. To a rootkit hunter which laymen can use it's a long way to go. Some rhetorical question questions. How to I create a Live DVD / USB to check my running system? Download such a Live DVD / USB image somewhere? How do I mount the internal hard drive? Or mount an internal full disk encrypted disk? Then run debcheckroot on it? Could this be fully automated so these tests can be run routinely, easy? Graphical user interface? Run debcheckroot fully automated at boot (from read-only boot medium such as Live DVD), verify all files, then continue booting from the internal disk (kexec)? That would be similar to the verified boot feature which is already a default feature in iPhone, Android, and ChromeOS. Can we get iPhone and Android Level Security for Linux Desktop Distributions? https://www.whonix.org/wiki/Kicksecure#iPhone_and_Android_Level_Security_for_Linux_Desktop_Distributions Cheers, Patrick Elmar Stellnberger: > Dear readers of debian-security > > I have just released debcheckroot-v2.0: > https://www.elstel.org/debcheckroot/ > > The new tool can be used to check a
Verified Boot, Secure Boot, dm-verity, debcheckroot
I am very interested in Verified Boot. Was wondering how it could be implemented on a Linux desktop distribution such as Debian. I would like to implement in Debian derivatives, that I maintain (Whonix, Kicksecure). Came up with some ideas which I will share here. https://www.whonix.org/wiki/Verified_Boot = User Freedom = Freedom Software can be compatible with Verified Boot. No user freedom restrictions required. While verified boot is often used to restrict user freedom, to prevent the user from modifications and installing another operating system, Verified Boot is not inherently bad. User-controlled keys are possible. https://blog.torproject.org/mission-improbable-hardening-android-security-and-privacy Quote > Nexus and Pixel lines support Verified Boot with user-controlled keys = Concepts = == Verified VM Boot Sequence without Secure Boot == (Same security level as Secure Boot?) Talking about VMs only in this concept. We could boot from a virtual, read-only (write protected) boot medium such as another virtual HDD or ISO. Such a boot medium which only contains a bootloader (shim or grub?) which only task is to verify the bootloader on the main hard drive that contains the bootloader, kernel, debian. That boot medium (such as IOS) could be shipped on Whonix Host through a `deb` package `/usr/share/verified-boot/check.iso`. Presuppositions: * the virtual BIOS cannot be flashed/compromised * host not compromised boot sequence: VM powered on -> virtual BIOS loads boot DVD ISO (or alternatively another hard drive) (contains a bootloader only) -> this initial bootloader signature is not verified but secure since boot from read-only medium -> verify bootloader on main hard drive -> bootloader of main hard drive does signature verification of kernel -> continue boot What we need for that: `grub-pc` (not `grub-efi`) with signature verification. * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939188 * https://savannah.gnu.org/bugs/index.php?56887 By not booting from that initial boot medium (for testing or if that was broken or so), users could do regular boots without verification of the bootloader on the main drive. From the perspective of the main drive, nothing would change. Except we'd enable grub signature verification of the kernel on the main drive. The boot medium should not load the actual kernel for simplicity of the implementation. Since it is read-only it cannot be easily updated. Kernel packages change and during kernel upgrades `/boot` and `grub.cfg` on the main disk changes. If `/boot` was write protected, that would fail. Therefore the initial boot medium is only a simplified alternative to EFI Secure Boot. By making the initial boot medium as simple as possible, i.e. only chainloading the next bootloader, it does not need frequent updates and does not need to be updated when kernel versions change. If we could make `grub-pc` (not `grub-efi`) use `check_signatures=enforce`, then maybe we don't need to port to EFI and/or Secure Boot soon and perhaps never? The disadvantage of this concept is that it is only as secure as Secure Boot. initrd could still be compromised: https://forums.whonix.org/t/enable-linux-kernel-gpg-verification-in-grub-and-or-enable-secure-boot-by-default/7894/30?u=patrick == Hash Check all Files at Boot == Higher security level as Secure Boot. Talking about VMs only in this concept. We could boot from a virtual, read-only (write protected) boot medium such as another virtual HDD or ISO. Such a boot medium which runs a minimal linux distribution which then compares against checksums from Debian repository on the main boot drive: * The MBR (master boot record) * The VBR (volume boot record) * [A] the booloader * [B] the partition table * [C] the kernel * [D] the initrd * [E] all files shipped by all packages There are tools that can help with checking all files on the hard drive such as `debsums`. However, while `debsums` is more popular, it is unsuitable. Quote https://www.elstel.org/debcheckroot/ > Usage of debsums instead of Debian-checkroot is strongly discouraged because debsums uses locally stored md5sums which can be modified by an attacker along with the files themselves. It has been meant for integrity checking not for security issues! Debsums furthermore does not provide an output as clean and neatly structured as checkroot and does not spot files additionally added to your system by someone else. A tool such as debcheckroot might be more suitable for this task. https://www.elstel.org/debcheckroot/ During development of Verifiable Builds experiences were made with verification of MBR, VBR, bootloader, partition table, kernel and initrd. Source code was created to analyze such files. https://www.whonix.org/wiki/Verifiable_Builds https://github.com/Whonix/Whonix/blob/master/build-steps.d/2800_create-report Extraneous files would be reported, with option to delete them, to move them to quarantaine and/or to view them. Initrd is
Re: not getting compromised while applying apt-get upgrade for CVE-2016-1252
What about Debian graphical installer security? Isn't that in meanwhile the ideal target for exploitation for targeted attacks? Because it will take a while until the Debian point release with fixed apt. And during the gui installer, the output of apt-get is not visible. And stuff during installer taking a long time is something users have been trained to expect. So I don't think it would raise much suspicion. If exploitation works, fine, if not, nothing was lost. Also Debian gui installer may be distinguishable over the network from already installed systems? Because first it's using debootstrap (perhaps with special options), then apt-get. The timing or something else could make it distinguishable over the network. Best regards, Patrick
Re: not getting compromised while applying apt-get upgrade for CVE-2016-1252
Julian Andres Klode: > (2) look at the InRelease file and see if it contains crap > after you updated (if it looks OK, it's secure - you need > fairly long lines to be able to break this) Thank you for that hint, Julian! Can you please elaborate on this? (I am asking for Qubes and Whonix (derivatives of Debian) build security purposes. [1]) Could you please provide information on how long safe / unsafe lines are or how to detect them? Ideally could you please provide some sanity check command that could be used to detect malicious InRelease files such as 'find /var/lib/apt -name '*InRelease*' -size +2M' or so? The problem is, - debootstrap can only bootstrap from one source such as 'http://ftp.de.debian.org/debian' - which still contains vulnerable apt. (Correct me if I am wrong, I would hope to be wrong on that one.) - bootstrapping from 'http://security.debian.org' is not possible [contains only security updates, not a complete repository]. - So in conclusion one has a chance to get compromised when bootstrapping from 'http://ftp.de.debian.org/debian' and then apt-get upgrading from 'http://security.debian.org'. Is there any way to break this cycle? Best regards, Patrick [1] https://github.com/QubesOS/qubes-issues/issues/2520
Re: not getting compromised while applying apt-get upgrade for CVE-2016-1252
Geert Stappers: > On Thu, Dec 15, 2016 at 09:43:59PM +0100, SZÉPE Viktor wrote: >> Quoting Patrick Schleizer <adrela...@riseup.net>: >> >>> Very short summary of the bug: >>> (my own words) During apt-get upgrading signature verification can be >>> tricked resulting in arbitrary package installation, system compromise. >>> >>> - https://security-tracker.debian.org/tracker/CVE-2016-1252 >>> - https://www.debian.org/security/2016/dsa-3733 >>> - https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1647467 >>> >>> How to upgrade from the insecure apt-get version 1.0.9.8.3 to the >>> patched apt-get version 1.0.9.8.4 without being compromised during that >>> upgrade? >>> >> >> You may download the new package >> http://security.debian.org/debian-security/pool/updates/main/a/apt/apt_1.0.9.8.4_amd64.deb >> (for amd64) > > By the command > > wget > http://security.debian.org/debian-security/pool/updates/main/a/apt/apt_1.0.9.8.4_amd64.deb > > >> and check its checksum >> https://packages.debian.org/jessie/amd64/apt/download >> >> $ sha256sum apt_1.0.9.8.4_amd64.deb >> >> f40e51afbbcf2b1e23442c4c3df064a02ddc27bdfbfb155839577dcb1dedb74a >> > > Then the acual install > > sudo dpkg --install apt_1.0.9.8.4_amd64.deb > > Which might yield (due my test on a non-up-to-date-system) > > (Reading database ... 42686 files and directories currently installed.) > Preparing to replace apt 1.0.9.8.4 (using apt_1.0.9.8.4_amd64.deb) ... > Unpacking replacement apt ... > dpkg: dependency problems prevent configuration of apt: > apt depends on libapt-pkg4.12 (>= 1.0.9.8.4); however: > Version of libapt-pkg4.12:amd64 on system is 0.9.7.9+deb7u6. > apt depends on libc6 (>= 2.15); however: > Version of libc6:amd64 on system is 2.13-38+deb7u8. > apt depends on libstdc++6 (>= 4.9); however: > Version of libstdc++6:amd64 on system is 4.7.2-5. > > dpkg: error processing apt (--install): > dependency problems - leaving unconfigured > Processing triggers for man-db ... > Errors were encountered while processing: > apt > > > > > Groeten > Geert Stappers > Need to do this for all 'apt'ish packages. https://www.whonix.org/wiki/CVE-2016-1252
not getting compromised while applying apt-get upgrade for CVE-2016-1252
TLDR: Is it possible to disable InRelease processing by apt-get? Long: Very short summary of the bug: (my own words) During apt-get upgrading signature verification can be tricked resulting in arbitrary package installation, system compromise. sources: - https://security-tracker.debian.org/tracker/CVE-2016-1252 - https://www.debian.org/security/2016/dsa-3733 - https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1647467 How to upgrade from the insecure apt-get version 1.0.9.8.3 to the patched apt-get version 1.0.9.8.4 without being compromised during that upgrade? Is it possible to disable InRelease processing by apt-get [for that upgrade or generally]? And have it check Release.gpg (which is provided anyway) instead?
Re: Which Debian packages leak information to the network?
Holger Levsen: > On Wed, May 18, 2016 at 06:33:52PM +0200, Jakub Wilk wrote: >> Could you explain how any of these tools leak any information "without a >> user's consent/expectation"? > > gnome-calculator contacts a web page/service with currency exchange > information *on every start*, I think that's a good example of the kind > of programs Patrick is looking for. > > Yes! :)
Which Debian packages leak information to the network?
Hello we are a privacy-centric distro based on Debian and wanted to know what Debian packages leak information about the system to the network without a user's consent/expectation. As documented on the page below, a system's security also depends on avoiding leaking any identifiable information to network adversaries by accident. Popcon, bts, wnpp-check are the noted examples so far (which we blacklist in our distro). Please help notify us of any other such packages. https://wiki.debian.org/TorifyDebianServices
Re: debcheckroot v1.0 released
Elmar Stellnberger: > Dear Debian-Security > > Having just released debcheckroot I wanna shortly present you my new tool: > It was originally designed as a replacement for debsums and has the following > qualities: > * full support of Debian repos reading /etc/[apt/]sources.list to fetch > checksums online > * it can check a Debian installation remotely from any Unix-like system just > requiring perl, gzip, bzip2 and tar > * it does not require a chroot into or any tools of the installation to be > checked; > debcheckroot is thus the better choice when it comes to security (chroots > may infect the freshly booted system); > The checkroot family of programs has already proven to spot various > rootkits not detected by chkrootkit and rkhunter > * usage of checksums in the package header by default rather than locally > stored ones (insecure if not backed up on f.i. an USB-stick); fast unpacking > on the fly into memory without the creation of temporary files > * nicely formatted output into files for later analysis > … and all of that in just a 930 lines of code. > > Though debcheckroot is currently still licensed under S-FSL I am ready to > re-publish under any license you like > if you can at least promise me to maintain the necessary support > infrastructure for it: > * sha256sums rather than the bit old fashioned md5sums > * checksums for all packages in the core distro (some are still missing > md5sums) > i.e. we would have to update debhelper to create shasums in addition to > md5sums and enable this for all packages > Here is a wishlist of mine: - put your code in git source code management - create a debcheckroot Debian package - upload that Debian package to official Debian repository (that would simplify creation of a Live DVD or Live USB with debcheckroot a lot; and get debcheckroot from a safer location; helps with publicity) - doesn't debcheckroot perfectly fit with the Debian reproducible team? They might be interested in to help with packaging and sponsoring upload. Please consider getting in touch with them. Cheers, Patrick
Re: Mandatory Access Control
Qubes is based on Xen. There are templates for Fedora, Debian and others. Windows can be a guest VM. Windows as a host is only a theoretical consideration for a theoretical port. [Hypervisor Abstraction Layer (HAL)] What convinced me of Qubes is, that for Linux a single explorable wifi driver is enough to already own everything, while with Qubes this code runs in a dedicated NetVM. For implementation details, see this pdf. https://www.qubes-os.org/attachment/wiki/QubesArchitecture/arch-spec-0.3.pdf It has a chapter "Secure GUI". Elmar Stellnberger: > No actually it is not Qubes what I am using. > I am using full blown qemu virtualization including a virtual wrapper > device for the graphics. It is for sure that even here the weakest point > is the emulation of the graphics card. I have even heard about HTML5 > code directly bugging your hardware via graphics acceleration (though > this is rather theoretical because it would likely need to be customized > to a certain graphics card). Nonetheless the weakness of Qubes is even > more the GUI dom where all other doms connect to and which has direct > access to the graphics hardware. Unfortunately I could not find any > details on how it is implemented in deed. > Additionally I found it somewhat irritating that the basic description > of the Qubes project talks so much about using Windows as a host. I > would never trust software which is entirely closed source. Please do > also note the following statement found in the intro when considering to > use Qubes: > "Sure, a single kernel exploit destroys this all" > > If you remember what I have told you about MAC systems then it was that > a single public accessible system call which is implemented faulty would > still compromise your system. Now consider that all current operating > systems including Windows, Linux and FreeBSD are huge monolitic > constructs making use of just two privilege levels/ security rings: user > and kernel mode. At the introduction of the i386 (which is now still > long ago) Intel suggested that at least three privilege levels would be > necessary to build a secure system: the innermost for memory and process > management, a middle ring for device and hardware drivers and the > outermost one for user space programs. According to my knowledge and to > what is public none of the operating system developers have followed > these precautions until today (Xen is a different case as it uses three > rings but not in the way as described above; actually it would need to > make use of all four rings provided by the protected mode interface to > be secure in theory - Nonetheless just believe me that things are not as > theoretical in practice as this description may make you believe.). > > Regards, > Elmar > > On 29.11.2015 22:05, Patrick Schleizer wrote: >> Elmar Stellnberger: >>> If you wanna ask me for my security solution it is qemu based and puts >>> the most vulnerable system components like browsers and email programs >>> into a virtual machine namely qemu which is maintained by the Open >>> Source commnunity. >> >> Sounds like Qubes. >> >> Cheers, >> Patrick >> >
curl security issue? - [SECURITY NOTICE] libidn with bad UTF8 input
Hi! Are you aware of this already? [SECURITY NOTICE] libidn with bad UTF8 input http://curl.haxx.se/mail/lib-2015-06/0143.html Haven’t found anything related on debian.org mailing lists and/or curl's changelog. Cheers, Patrick -- 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/55944bbd.4050...@riseup.net
Re: apt-build - Authentication warning overridden. - security issue?
Brett Parker: On 18 Mar 16:27, Patrick Schleizer wrote: Hi, I was running: sudo apt-build install ccache And the output contained a message: WARNING: The following packages cannot be authenticated! ccache Authentication warning overridden. Have you tried updating the debian-archive-keyring package, and rerunning apt-get update? Yes. All packages were 'apt-get update apt-get dist-upgrade' before running this experiment. Earlier in this thread we figured out why this is happening. Cheers, Patrick -- 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/557c4407.9020...@riseup.net
Re: apt-build - Authentication warning overridden. - security issue?
Dear security team! Paul Wise thinks this is a security issue Paul Wise: This is a security issue, [...] I was running: sudo apt-build install ccache And the output contained a message: WARNING: The following packages cannot be authenticated! ccache Authentication warning overridden. Is this just how apt-build works or could this be a security issue due to installing unauthenticated packages? public: yes [posted on debian-security mailing list] versions affected: all suites how to fix: no idea Cheers, Patrick -- 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/550aa61c.9080...@riseup.net
Re: apt-build - Authentication warning overridden. - security issue?
Holger Levsen: I think you probably just need to run apt-get update before apt-get install... I did that, I am sure of it. Reproduced this on two different systems. Cheers, Patrick -- 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/550ab274.50...@riseup.net
Re: apt-build - Authentication warning overridden. - security issue?
Holger Levsen: Hi, On Donnerstag, 19. März 2015, Patrick Schleizer wrote: I think you probably just need to run apt-get update before apt-get install... I did that, I am sure of it. Reproduced this on two different systems. can you put the output of apt-get update and apt-cache policy on paste.debian.net? Done: http://paste.debian.net/162076/ And for completness sake, I also added the output of apt-build install hello. Cheers, Patrick -- 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/550ae629.4050...@riseup.net
Re: apt-build - Authentication warning overridden. - security issue?
Cyril Brulebois: Patrick Schleizer adrela...@riseup.net (2015-03-18): Hi, I was running: sudo apt-build install ccache And the output contained a message: WARNING: The following packages cannot be authenticated! ccache Authentication warning overridden. Is this just how apt-build works or could this be a security issue due to installing unauthenticated packages? It probably wouldn't happen if the source snippet added at installation time would be using “deb [trusted=yes]” instead of just “deb”. Manually editing /etc/apt/sources.list.d/apt-build.list seems to confirm that. [...] That works for me on jessie, but not on wheezy. But... Doesn't this just silence the warning? I mean, adding '[trusted=yes]' to the local apt line is safe, sure. But the original issue was, that the message 'Authentication warning overridden.' is auto generated. I.e. apt-build used apt-get in a way to ignore such warnings. There is one line in apt-build source code that includes '-o Apt::Get::AllowUnauthenticated=true'. So if some other packages from a remote repository could not be authenticated, another 'Authentication warning overridden.' could happen? For testing purposed, I removed the part '-o Apt::Get::AllowUnauthenticated=true' from apt-build. 'apt-build install' is still functional. I don't understand the code to say if that is a good idea. What do you think? Should that part be removed? Cheers, Patrick -- 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/550aee86.7000...@riseup.net
apt-build - Authentication warning overridden. - security issue?
Hi, I was running: sudo apt-build install ccache And the output contained a message: WARNING: The following packages cannot be authenticated! ccache Authentication warning overridden. Is this just how apt-build works or could this be a security issue due to installing unauthenticated packages? Cheers, Patrick -- 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/5509a78a.1070...@riseup.net
deterministic linux kernel SameKernel with grsecurity by mempo?
Hi, what is your opinion on the deterministic linux kernel SameKernel with grsecurity by mempo? https://wiki.debian.org/SameKernel https://github.com/mempo/mempo-kernel Cheers, Patrick -- 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/54edd9ac.7060...@riseup.net
Re: Archive GPG key expiring process
Yves-Alexis Perez: On ven., 2014-10-17 at 17:14 +, Patrick Schleizer wrote: Debian has no good mechanism to revoke apt keys in case of compromise, neither a way to inform users in emergency situations: https://lists.debian.org/debian-security/2013/10/msg00065.html The only information is that thread (which is true for this one too) is that you failed to contact the relevant people. Answers in, - https://lists.debian.org/debian-security/2013/11/msg00011.html - https://lists.debian.org/debian-security/2013/11/msg00014.html - https://ftp-master.debian.org/keys.html are sufficient. Otherwise, what are the relevant people, how to contact them? Perhaps we have a different understanding of good mechanism to revoke apt keys in case of compromise, neither a way to inform users in emergency situations? Cheers, Patrick -- 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/54427148.8070...@riseup.net
Re: Archive GPG key expiring process
Yves-Alexis Perez: On sam., 2014-10-18 at 13:55 +, Patrick Schleizer wrote: Otherwise, what are the relevant people, how to contact them? You can find some hints in https://lists.debian.org/debian-security/2013/10/msg00066.html If it's really that hard, here are some pointers. DSA: https://dsa.debian.org/ (look for “contact”) FTPteam: https://ftp-master.debian.org/#ftpteam (and ftpmas...@debian.org) From: https://lists.debian.org/debian-security/2013/11/msg00018.html The DSA told me it doesn't relate to DSA and the ftpteam didn't reply. (Was a mail to ftpmas...@debian.org - never got a reply.) What I could have done or could do is going to #ftpteam, but it didn't seem appropriate to me. -- 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/5442f2c4.3080...@riseup.net
Re: Archive GPG key expiring process
David Hubner: Hi, I am just wondering about a hypothetical situation where the master GPG key used for signing the debian archive was stolen. After creating a new master key and getting a new public key into the debian-keyring package, how would you get that to users? I mean if you resigned the release file after the attack happened with a new master key that would mean nobody could apt-get the debian-keyring package for the new public key. I am wondering if I am missing something. Is there a process for this possibility? Thanks Debian has no good mechanism to revoke apt keys in case of compromise, neither a way to inform users in emergency situations: https://lists.debian.org/debian-security/2013/10/msg00065.html An apt key revoker should be written: https://lists.debian.org/debian-security/2013/12/msg00031.html It's on my list, but I never got to it: https://github.com/Whonix/Whonix/issues/125 So anyone feel encouraged to do something about it. Cheers, Patrick -- 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/54414e7d.7040...@riseup.net
Re: Debian mirrors and MITM
Peter Palfrader: On Fri, 30 May 2014, Joey Hess wrote: Alfie John wrote: Taking a look at the Debian mirror list, I see none serving over HTTPS: https://www.debian.org/mirror/list https://mirrors.kernel.org/debian is the only one I know of. It would be good to have a few more, because there are situations where debootstrap is used without debian-archive-keyring being available, and recent versions of debootstrap try to use https in that situation, to at least get the weak CA level of security. That doesn't buy you anything. Mirrors, even if you trusted them, don't use authenticated syncing protocols. Looks like another issue worth fixing under the encrypt/authenticate all the things credo. -- 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/5389b3db.5020...@riseup.net
Re: Debian mirrors and MITM
Joey Hess: [...] there are situations where debootstrap is used without debian-archive-keyring being available, [...] Please elaborate, which situations are these? -- 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/5389b537.4020...@riseup.net
Re: Debians security features: Please help us!
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Paul Wise:
On Sun, 2014-05-18 at 21:53 +0200, herzogbrigit...@t-online.de
wrote:
So: Please help us to complete the table.
Why didn't you just use the Ubuntu script to automatically fill it
out?
https://bazaar.launchpad.net/~ubuntu-security/ubuntu-cve-tracker/master/download/head:/dumpfeatures-20100722110958-2t0734uoe0rgz9ww-1/dump-features
Because
it would need considerable mental resources to get it working
on Debian. Also a lot python source editing would be required.
You might think it autodetects security features. It doesn't. Example
code:
add_status('kexec', 'trusty', 'sysctl', AVAILABLE)
So instead of asking people to edit the wiki, to autogenerate that
page, we would have to ask people to send patches for a python script.
That script may be suitable for an employee having the task to keep
that wiki page updated (Ubuntu). For a more volunteer like approach
(Debian), I think just writing the wiki page is better.
-BEGIN PGP SIGNATURE-
iQJ8BAEBCgBmBQJTegElXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2RTk3OUIyOEE2RjM3QzQzQkUzMEFGQTFD
QjhENTBCQjc3QkIzQzQ4AAoJEMuNULt3uzxIfvMP/1FIiM2+/nHqjHqBkGCcnqiC
3RuF7EuoPRoEBm6myf9FVW9i7oUpSL/0/sFBgVyGaaDUNVm/Y2aLXT0xaXYa1Cak
kIool2n5ZEqWMK0cT1JR2wCPw5pss5J9PGjUGEyXl9VJZfHdQA1R6NCdj0Lb6yAJ
dvPBQZcXs4gcR/8x9A5ZlbUUcydRF7s7mwXmQBQxxGlJf1CsCmbU1kTstoJYYtQE
LkdOpwbnMUEwBFLDY3OsQvbTZieTRDs2FBLWsjHdTMbDXUWp+deEd9Jt8GNBgXnG
jt7RRBCbcAI2Nt6vbgBZ/cW8vuJcbp5g/n6Xy2mIeu5ImcYCxlxpqFmzitK5UOV8
tQ02D5TUTuzG/uKggQ227LKpH30dN64Jx0PPhYCD8RiSQKhVCXsLCfEaRuM/44ZB
utj8idTn9CuRwWbnNitffgAHk92AiRy8F46WXyx7MS1yvX2Kx+5aunb1f+WKo79j
Q5sIg3+geJujen3Hx3uoNjhDr61Wet0kxuFaPTyFQMdwR+lRkgxK1hCzMvhvKPP6
6ZZ4lo4v7HMl814if/UH3OiUWSzy1p13wtm9A/GCiFTl2kiWRJagft9iKpE44xEp
12iGnqHPqzGOBb6t+YAQzdEiWymbKQNVSsHYdHOpma4E6+8qyi8y8Q4inwrsUIeP
C1dzbWd/U3PkbFFWSONO
=vTS0
-END PGP SIGNATURE-
--
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/537a0131.50...@riseup.net
Re: AW: Debians security features: Which are active?
Paul Wise: On Sun, 2014-05-18 at 01:41 +, Patrick Schleizer wrote: Got started: https://wiki.debian.org/Security/Features Anyone knows how to view (as a non-admin) the wiki markup of https://wiki.ubuntu.com/Security/Features ? (I would like to learn by example how wiki tables are made in moin moin wiki software.) Use the raw text action: https://wiki.ubuntu.com/Security/Features?action=raw For some reason even when using the whole raw page from Ubuntu and pasting it into a Debian wiki page, it still looks different. Table still isn't using dotted border. -- 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/537a01b7.6000...@riseup.net
Re: Debians security features in comparison to Ubuntu
Joel Rees: He told me to use Ubuntu instead. He explained that with the fact, that Ubuntu has more security features enabled than Debian (also more compiler flags for security) in a fresh install. He gave me a link to the following site: https://wiki.ubuntu.com/Security/Features That's a good list of all the currently fashionable security features for Linux. Some of the items in the list are meaningful, some are not. Most might be if you know what you are doing with them. None of the meaningful items in that list are unavailable on Debian, and the defaults are reasonably secure in Debian. The problem is, that Debian lacks a page similar to: https://wiki.ubuntu.com/Security/Features As you can see, that https://wiki.ubuntu.com/Security/Features page looks impressive to new users. I guess Debian is losing a few users to Ubuntu, because Debian does not have such a page. This will be an issue with any OS you choose, even seriously secure OSses like openBSD. Is OpenBSD a seriously secure OS? Last time I checked, OpenBSD didn't provide signed packages for the package manager by default. Using OpenBSD signed packages for updating only seemed ridiculously complicated. http://www.openbsd.org/faq/faq1.html: OpenBSD is thought of by many security professionals as the most secure UNIX-like operating system Well, for experts eventually, not for normal users! And I am wondering which security professionals they are quoting and from when these quotes are. Do not surf the web as root or as any administrator login id, of course. Speaking of admin login ids, it's a good idea to have one non-root login id that you only use for administrative tasks. And you should avoid getting onto the web when logged in with the admin id. Which means you need another id for general use, which makes two strong passwords, three if you allow root login. After reading the following blog post http://theinvisiblethings.blogspot.fr/2011/04/linux-security-circus-on-gui-isolation.html it seems to me, that user account level isolation isn't very strong. -- 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/53774bb8.9020...@riseup.net
Re: Debians security features: Which are active?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 herzogbrigit...@t-online.de: Thank you for all your replies. I understand that the user is important for security, but it's a difference whether you start from scratch or you can work with somethink prebuilt. So, could you tell me, which of the following securit features are enabled in Debian by default and which I have to activate manually: Stack Protector Heap Protector Pointer Obfuscation Stack ASLR Libs/mmap ASLR Exec ASLR brk ASLR VDSO ASLR Built as PIE Built with Fortify Source Built with RELRO Built with BIND_NOW Non-Executable Memory /proc/$pid/maps protection Symlink restrictions Hardlink restrictions ptrace scope 0-address protection /dev/mem protection /dev/kmem disabled Block module loading Read-only data sections Stack protector Module RO/NX Kernel Address Display Restriction Blacklist Rare Protocols Syscall Filtering Block kexec Paul Wise recently started a thread on this mailing list: goals for hardening Debian: ideas and help wanted What about making a wiki page in Debian wiki listing what's implemented with references? If you wish, I can try to start that table. I would be interested myself what's implemented. -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJTd0yAXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2RTk3OUIyOEE2RjM3QzQzQkUzMEFGQTFD QjhENTBCQjc3QkIzQzQ4AAoJEMuNULt3uzxI8HsP/RfDxaehxC0QJW+I9zr60gJh OYvYAWUaNubF2fZlbI+u1OShDYYgTplc4iVzzi9zAtCn5V88rpH01Ehnj22RgmL+ 38oIvbmae/zRXt0CdAUIJFf6HY53P9scUGWPq0INcYl6TkIAHH7lUzY3yWGzTWy9 /M5Nf6c9g1BWU0Sjrsiik17pi/01FWgAe8kkI7To3jhiYypSbgAZsYFQTJg5RtZK ZJcNTUYFrIiW5z/dLNSG400oG+SFb8B5kNp+5lImdIbxVzRKs8WghH/QgUA5Uxzk FV+6VP9hhtPx59/zT4YSVLOTjQkuwV2ZK0esRL2OuzIlXdBmG778sYE/vJZBY2Z3 G9kupqefW3RUkmw8kKdmW9aYg1Df++rQq1evP54N6rH4rqxVyE1MNdNwETN7aYHw Z6Yx7mdZ8AqbWD3UTKQ8Z70jiMm/1S9iTbJ7K0/GkcUhfNg4VMcrlhUxUiQqJZMG b04TnBtdL+rgTi+vPd0SFFI2stmnCCthmnR56SnvnX3+IZ98ODBYm/DlaJPVhFNm 0h4MCGJFe463dl1WWFbMJ3mY0G4M96KkpakEpzuMBYUHHV2zjATonb+KQ/4Hwyhi IzMTNwpUVH/fwEU6lznUX9bKwf9koEAioJxSyTvI3es/NKWIycdvW3Hg2dGuGyCl 4Lm3ImCVtqx/hN+dkcJN =WSpN -END PGP SIGNATURE- -- 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/53774c82.5070...@riseup.net
Re: AW: Debians security features: Which are active?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 herzogbrigit...@t-online.de: Yes it would be great if you can start with such a page. Use the Ubuntu table as a template to start. I'll try to help as much as I can in the wiki. Many Linux-Distros have a security features page in their wikis. So why not also Debian? Got started: https://wiki.debian.org/Security/Features Anyone knows how to view (as a non-admin) the wiki markup of https://wiki.ubuntu.com/Security/Features ? (I would like to learn by example how wiki tables are made in moin moin wiki software.) Alternatively, does anyone know how to make to add a dotted border to the wiki table? -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJTeA+4XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2RTk3OUIyOEE2RjM3QzQzQkUzMEFGQTFD QjhENTBCQjc3QkIzQzQ4AAoJEMuNULt3uzxIjEoP/3VGsbenT78FPLT4W/wq/bwB FjsqONmDZgAdt474XAAo7SnrFzbUkHrRvYgIqKtUu9g9ftYtwGW+9Ld4ZPuPAVsl Or1cP+np1idautIrhN/qdNZuohTciE1S+bGT9keh//F3VeEWKPezMZSuUFPFhZXG DyInHN8grp3blxuXsDo7cRW1ZtDp/+YwRWs/bsjLkpkCVdPkDpAf7qzn4UvmRr9T qEPw47irms39Qkz9Jc3MLRuFRivjgiQUGUMuvmYwI60x5CRvptjOjlkot7Q0h4R1 JjYTIbxqQTl056RYs4n/EAE5UrrQZuxrMAXDQa5KJwmb097fd6MXSBE548Smzmev +9Eh+dZkCEufzZnEcgwNe7MOVoHoom6FLvNVWOay0VCeGXPKHs3CwRlnq5/EhSwU ZvszcPUEIsk1mXddPKkBalGvtQB1+v2NjqHivCZARdSaJIBxsD4rNVaVGhttIF4h B87V/vB7nbOkZ92U5HHgzEdfuOZFbDfcnRYguGEVpL0Ca/O/q1AWE9NTOd6myoYW 9nFSkQN0U5IkecAHQ9J25fbPi7lUh0xJN8Q/PGwqYb6DMGg720hEIHe7lwgnVBNo tG26NIR5WoctmUgznA+59NYVQGA/JqCCCX+q1doIUU1Onm12qGFHPPc0fl14jyCO 61E5l0ydLnLkLArOYU9q =vrym -END PGP SIGNATURE- -- 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/53780fc5.70...@riseup.net
Re: goals for hardening Debian: ideas and help wanted
Marko Randjelovic: I was thinking about some kind of wizard: - create a chroot if doesn't already exist - create a launcher for your DE - create a shell script to run a program from terminal or a simple WM hint: chroot $CHROOT_PATH su - $USER -c $command_with_args chroot is not a security feature? As far I understand, chroots in Debian/Fedora aren't jails. Source: https://securityblog.redhat.com/2013/03/27/is-chroot-a-security-feature/ -- 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/535f926e.3080...@riseup.net
Re: goals for hardening Debian: ideas and help wanted
Marko Randjelovic: On Tue, 29 Apr 2014 11:52:14 + Patrick Schleizer adrela...@riseup.net wrote: Marko Randjelovic: I was thinking about some kind of wizard: - create a chroot if doesn't already exist - create a launcher for your DE - create a shell script to run a program from terminal or a simple WM hint: chroot $CHROOT_PATH su - $USER -c $command_with_args chroot is not a security feature? As far I understand, chroots in Debian/Fedora aren't jails. Source: https://securityblog.redhat.com/2013/03/27/is-chroot-a-security-feature/ it is not really a security feature, it is closer to what we would call a hardening feature. Well, we have the word hardening in the subject, I'm not sure what OP meant, probably he ment more security then hardening, but grsecurity which is mentioned in wiki[1] contains features to prevent breaking out of chroot, so combined with grsecurity chroot might be called a security feature? [1] https://wiki.debian.org/Hardening/Goals I see. Sure, if possible, that would be an interesting security feature! -- 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/535fe943.6070...@riseup.net
Re: debcheckroot v1.0 released
Hi Elmar! This is a most interesting tool! The opensuse logo on http://www.elstel.org/debcheckroot/ is confusing, since this is a Debian tool. This might scare of interested people. As Debian package headers do not use to be signed I think you are mistaken here or maybe I misunderstand. When you have a Debian medium you trust (such as a Live DVD from a trusted source), we can regard keys in /etc/apt/trusted.gpg.d/ and /etc/apt/trusted.gpg as trusted. For example http://ftp.us.debian.org/debian/dists/jessie/InRelease and http://ftp.us.debian.org/debian/dists/jessie/Release.gpg are gpg signed by the Debian archive key. So when you run apt-get update followed by apt-get download $packagename, you get a package that is signed by Debian archive key. You can then unpack the package, create sha sums of all it's contents and then compare with the installed system. Sure, it's not perfect, but worth verifying this trust chain. It would be better/cleaner/simpler to implement this if Debian would publish signed sha sums files of all package contents. Lot's of opportunities to improve Debian in order to implement such a feature here. - I once attempted to write a script that can be run from a Live DVD to audit an installed Debian on hdd or to mount an image with Debian and to audit that. That script can be found here: https://github.com/Whonix/whonix-developer-meta-files/blob/master/deprecated_code/verify_build This approach seemed futile to me. At least for now. There are too many files, that are automatically generated created by postinst scripts. For example /usr/lib/pymodules/python2.7/**/__init__.pyc gets automatically generated. Even worse, the file is non-deterministic. In future situation may improve: https://wiki.debian.org/ReproducibleBuilds It would also help if Debian had an OEM mode. Links to these discussions can be found here: http://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20131209/10.html - For Whonix, Verifiable Builds have been implemented, which is similar to this tool: http://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20131209/09.html As a maintainer of Whonix and interested in that feature, I am naturally interested in your tool. Why you should not use debsums Please don't be so harsh on debsums. It's not for backdoor detection, but great as a simple integrity check. Cheers, Patrick -- 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/53401fdb.9010...@riseup.net
Re: debcheckroot v1.0 released
Elmar Stellnberger:
As Debian package headers do not use to be signed
I think you are mistaken here or maybe I misunderstand. When you have a
Debian medium you trust (such as a Live DVD from a trusted source), we
can regard keys in /etc/apt/trusted.gpg.d/ and /etc/apt/trusted.gpg as
trusted.
For example http://ftp.us.debian.org/debian/dists/jessie/InRelease and
http://ftp.us.debian.org/debian/dists/jessie/Release.gpg are gpg signed
by the Debian archive key.
Ah, many thanks for that advice. I had just looked at the Release file
which was and still is not signed (am I right?! - have just checked this
file).
You can either directly use InRelease or what I find cleaner, verify
Release using Release.gpg.
However the InRelease file is signed and should contain all the
relevant information: a signature for every Packages.gz which in turn
does contain checksums for every package.
I think the goal is to keep (In)Release as small as possible to save
server load. But that is okay.
The (In)Release file authenticates the Packages (ex:
main/binary-i386/Packages). And the Packages file therefore contains a
signed [indirectly, but sufficient!] signature [sha sum] of all packages.
Ex:
Package: python-stem
...
Filename: pool/main/p/python-stem/python-stem_1.1.0-1_all.deb
...
SHA256: 4cdf5d54f230390452181007b0619fe7123328c95373feb73c7c4138a347a34e
...
And after extracting for example python-stem_1.1.0-1_all.deb, you can
create sha sums of it. Then compare. Sure, having a shasums file
downloadable and listed inside Packages file is a missing feature.
As far I can see, there are currently no breaches in the verification
chain. Sure, there is room for improvements, such as also checking
signatures against the maintainer, not just Debian archive key,
reproducible builds, random rebuilds checking against distributed
community (DHT) and more. Anyway, for purposes of debcheckroot, the
current verification methods should suffice.
This approach seemed futile to me. At least for now. There are too many
files, that are automatically generated created by postinst scripts. For
example /usr/lib/pymodules/python2.7/**/__init__.pyc gets automatically
generated. Even worse, the file is non-deterministic.
Well, of course debcheckroot is not a 'silver bullet' nor an ultimate
remedy.
Sure. This wasn't meant as a criticism. I applaud you for writing this
tool! Because I already do imagine the future. When OEM mode and
reproducible builds become standard features, these are components and
debcheckroot is one component. debcheckroot will then become the 'silver
bullet'.
However I have already used it to spot rootkits on some core binaries
and the glibc which did not hide in *.pyc or other files generated on
the fly.
Sure.
As far
as that would only concern *.pyc one could even consider to remove all
these files
That will be difficult without OEM mode. There are loads of auto
generated files and loads of non-deterministic auto-generated files.
Anyway. This issue will be solved, when dpkg gets a reset to prestine
/ OEM feature.
Yes, perhaps you are right. However most people whom I know have not got
that, yet ('...').
I know. :) Because I once raised the question, if a tool such as
debcheckroot exists in Debian and debsums was recommended.
--
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/53404498.7000...@riseup.net
gpg signatures for Jessie images
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi! Stable, http://cdimage.debian.org/debian-cd/7.3.0/i386/iso-dvd/ contains gpg signatures. Wheezy, http://cdimage.debian.org/cdimage/weekly-builds/i386/iso-dvd/ does not contain gpg signatures. Can you offer gpg signatures for Jessie as well please? Cheers, adrelanos -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJS2svSXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2RTk3OUIyOEE2RjM3QzQzQkUzMEFGQTFD QjhENTBCQjc3QkIzQzQ4AAoJEMuNULt3uzxIPAkQALO/CLg8lhLLXGuc+NfJyNLo 0onGgBUon6Rfn7m5B2cEHKH7Y/1u3bIxVnDzJtJYgXoNrdVkJtcTdYqP4/OHqA0I jaV0TqKQV0Fx1LumqQUkbMS/yWsvpyHMohWMtaaLefHj2CXeB3v1GzqC2y/ka8ZD 1a4aS7l0vv0AL+T/Q9ULlNqQfmHNz5+/nybLlHumVhfnx/sEePE2hpL4kR1KNRBO BiGo+SvDDm0zyk078CHDHvPV98X8IRuv08r7xOwgBRifgXd5Ymo0T9oN9vraR/Xl WKN328aT/6no8TGQGdK4tpNRRa674wxmun5AaMByhIg3Ywmr6aWraZPZT6Lw502P ovb7H1OIMEezr3lgrC1o4xl3Kd0ybULdP6fWTyxIUXaSw1qum6WSCiniCz1TdZnb vuW3bWtOv8dxJOT2K8faHQMFPHYgqSoyGtMpbJ16JmKODlSf4uHnN0uDduDu7lTs 64irj4/M1xmVwjIXDoV5TKTiOc6jM5BEHQkT2MaAwwK+HFETQlwXcuW7Fqt6nUxk VCxUTipuKfYSBOvoNHwX+Dz4PWKbpxWPK31bdZ4qWPf1I8tkPhRK7skJM1l0HU7K 7gyF6soXbUpBDI975MLcYT2YkezdzalQPfK3468EDOJ9UDX1xF2FrmuKfWHMziLq Xssn61nvbf78SlsY5spf =jyOS -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52dacbd4.8020...@riseup.net
