Re: goals for hardening Debian: ideas and help wanted
Hi Paul, On Sun, Jun 08, 2014 at 10:13:27AM +0800, Paul Wise wrote: We kind-of already support that; Debian Live is essentially that. What would official support for read-only root look like to you? Option in the installer? Probably fix the last bits of details that makes a read-only install not totally functionnal. Currently, it appears you can pass the read-only option as extra-flags for / when configuring the filesystem, but you still need to adjust: mtab - /proc/mounts adjtime - /var/lib/adjtime blkid.tab - /var/local/blkid.tab You still need a /tmp as tmpfs, too - as far as I can see we still are having a /tmp under / https://wiki.debian.org/ReadonlyRoot That page needs updating, some of the bugs/issues are fixed. Since you are familiar with the use-case, could you do that? The /etc/network/run issue has been fixed (but this is implied in the page) What I see seems to be still relevant (ie. /etc/mtab still needs to be symlinked to /proc/mounts on wheezy, for example) Bug 156489 is still there on wheezy (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=156489) # LANG=C /etc/init.d/hwclock.sh stop Saving the system clock. hwclock: Could not open file with the clock adjustment parameters in it (/etc/adjtime) for writing: Read-only file system hwclock: Drift adjustment parameters not updated. Hardware Clock updated to Sun Jun 8 10:53:36 CEST 2014. The workaround is really obvious: mv /etc/adjtime /var/lib ln -s /var/lib/adjtime /etc I could not confirm the other issues (such as cups or alsa I'm not using on this machine) the only annoying thing is the 'mount: / is busy' issue Have you reported this bug? Not yet, for multiple reasons: * I can't seem to find the real culprit - checkrestart fails to spot any relevant information, and neither lsof nor fuser -c could help me at this point * I'm using a customized grsec kernel - I first need to confirm that the issue also appears on a vanilla kernel * I'm using wheezy/sid mixed packages, and here again a real vanilla install will be necessary to du further tests But I'll check that next time moire thoroughly, as the issue almost always pops when updating a package. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140608092547.GA21027@proliant.localnet
Re: goals for hardening Debian: ideas and help wanted
On Thu, Apr 24, 2014 at 10:57:39AM +0800, Paul Wise wrote: I have written a non-exhaustive list of goals for hardening the Debian distribution, the Debian project and computer systems of the Debian project, contributors and users. If you have more ideas, please add them to the wiki page. Would a read-only root filesystem goal be feasible ? Might not be by default, but this helps a bit, and it may even prevent root from breaking things by accident. I don't know if this can be considered a security feature, though, but probably in some way. https://wiki.debian.org/ReadonlyRoot I have been using my main debian server for few years with a read-only /, and the only annoying thing is the 'mount: / is busy' issue after an apt-get update phase, but otherwise things are fine. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140607133147.GA16674@proliant.localnet
Re: goals for hardening Debian: ideas and help wanted
On Sat, Jun 7, 2014 at 9:31 PM, Xavier Roche wrote: Would a read-only root filesystem goal be feasible ? We kind-of already support that; Debian Live is essentially that. What would official support for read-only root look like to you? Option in the installer? https://wiki.debian.org/ReadonlyRoot That page needs updating, some of the bugs/issues are fixed. Since you are familiar with the use-case, could you do that? the only annoying thing is the 'mount: / is busy' issue Have you reported this bug? -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKTje6Ew50tcJdREB9tn=yosowmankkjc8mju3lz9yxyc9f...@mail.gmail.com
Re: goals for hardening Debian: ideas and help wanted
Hi, Giacomo Mulas wrote (24 Apr 2014 16:49:20 GMT) : Good to know, actually I had tried apparmor quite some time ago and did not try again. I will give it another spin as soon as I can. https://wiki.debian.org/AppArmor/HowTo :) However, I do not agree that I should file bugs against apparmor if a debian package does not work properly, it should go to the package manager (and maybe cc to some apparmor expert team). It cannot be the maintainer(s) of apparmor to have to shoulder the effort of creating and maintaining profiles for all debian packages. They may be called in for support, but regular package maintainers should be involved IMHO, otherwise it will never really take off and provide significantly better security. IMO, the bug should be filed against the package that ships the profile: it's not a bug in the apparmor package, that other packages may feed it with a buggy configuration. Now, most package maintainers currently don't use AppArmor, and they may upload AppArmor profiles (e.g. provided by upstream) that won't work as-is in Debian. We have no clear consensus that we should invest time, distro-wide, to support AppArmor in Debian, so I don't think we can blame anyone for this. At least they're giving a chance, for anyone interested, to actually test these profiles, enjoy it when it works, and report bugs otherwise. If the profile is shipped in the same package as the software (as opposed to what comes from apparmor-profiles), and if the maintainer lack the resources and/or the interest to take care of such bugs, then they still have two useful options: * ask the AppArmor profiles team (Cc'd) for help to fix the profile, in order to go on shipping it along with the software it's about; that would be my preferred solution, whenever applicable; * drop the profile from their package altogether, and ask pkg-aa-profiles for inclusion in the upcoming apparmor-profiles-extra package. I still hadn't time to properly announce the pkg-aa-profiles team, so no wonder it hasn't taken off yet. Help is welcome: https://wiki.debian.org/AppArmor/Contribute If interested in more background information: https://lists.debian.org/debian-security/2014/01/msg8.html Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85r431h513@boum.org
Re: goals for hardening Debian: ideas and help wanted
Hi Kevin, Kevin Chadwick wrote: Debian developers not being able to upload security fixes is part of the mix but then I would guess you could more easily bring down the TOR network too than a private VPN and filtering would be much more difficult so I would say TOR is not *optimum* for security or availability and obscurity is no real security though perhaps very occasionally the best possible ;-). I'm not saying that DD's should use Tor. But a VPN might not be more secure. Tor is more complex, less proven, had more past exploits and crucially I believe? generally more reliant on external infrastructure. It's primary aim is privacy and not a simply secure protocol. I include SSH when I say VPN too but host security is paramount in any case. Software VPNs have had vulnerabilities over and over again, the last one being heartbleed (that also affected commercial VPN products such as Cisco ASA/PIX and some Juniper devices). IPsec hat to be revised and is often implemented in a way that defies the standard that has been under heavy criticism by the cryptography community (e.g. https://www.schneier.com/paper-ipsec.html) Bashing on Tor does not help here. Aaron signature.asc Description: OpenPGP digital signature
Re: goals for hardening Debian: ideas and help wanted
previously on this list Tzafrir Cohen contributed: A wide misconception. Chroots are easily implemented and add security almost for free Not completely for free. You now have an extra mini-system to maintain. (often /dev/log is all that is needed) and so can be You completely misunderstand. Many daemons have chroot config options for security reasons. I am asking does Debian use them by default and if not why not. used by default without any potential problems, they also never bring new risks unless you forget to unpdate them. You don't need to update them, they are basically empty and created on daemon startup with perhaos one or two files like a dns root key for unbound which is then self maintained (better if writes could be avoided though). I am talking about dropping an unpriviledged process permissions to next to nothing running with no shell and no filesystem access so that any exploit in the network/any input code is far less likely to get any further. It's also worth mentioning systemd-nspawn: http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html Not at all, it hasn't been tested for this, isn't supported by daemons that crucially use priviledge seperation, which involves forking children so a tiny process doing what root needs or a tiny process doing the dangerous stuff in a chroot as an unpriviledged user or a combination of both and any wrong communication means the priv parent dies), sounds like it does what most Linux admins think chroot is only good for and talks about all sorts of stuff that would make any chroot in this way pointless. more powerful I expect means less secure in this usage. p.s. this is proper security in quality daemons implementing application specific security not polkit/systemd rubbish. Whilst you have got me to mention systemd I shall bring something up that has yanked my chain. I suppose the debian page https://wiki.debian.org/Debate/initsystem/systemd Is just written by random developers and is not official or speaking as a debian collective because it is very unbalanced indeed. Embedded more performance less memory blah blah well that depends as systemd is NOT compatible with application specific embedded that basically is what embedded is all about and the Linux kernel is atleast for now and would be forked otherwise. I could argue further about larger systems but I won't bother, it would just be twisted and move away from the main point anyway. http://lists.busybox.net/pipermail/buildroot/2011-November/047612.html -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/25453.25357...@smtp118.mail.ir2.yahoo.com
Re: goals for hardening Debian: ideas and help wanted
On Fri, 02 May 2014 10:55:15 +0200 Aaron Zauner wrote: Bashing on Tor does not help here. The page suggests all devs use Tor to avoid being targetted. I am saying, does it accomplish that and is is best practice. Should they be hackable even if they are targetted or stumbled upon. I find that highly questionable and I am suggesting other simpler policies will be far more effective. Hiding is fine but not at the cost of complexity where security (confidentiality/protection/unexploitability) is paramount. I also mentioned ssh which I believe all the devs are using already. I am not going to say which VPN/SSH is best for the devs, I wouldn't know. I expect they would not choose commerical proprietary insecure CISCO you compare to TOR though in any case. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/519419.15824...@smtp146.mail.ir2.yahoo.com
Re: goals for hardening Debian: ideas and help wanted
previously on this list Kevin Chadwick contributed: all sorts of stuff that would make any chroot in this way pointless. more powerful I expect means less secure in this usage. p.p.s. why implement yet more code and complexity into systemd for preventing device files when you can just use the nodev filesystem flag. Yet another classic example of pointless arguably, more likely detrimental feature creep/steal and even worse when duplicating existing functions that can be applied more universally. Perhaps because of this quote taken from the opening page of a book about Ada and high integrity software. There are two ways of constructing a software design. One is to make it so simple that there are OBVIOUSLY no deficiencies. And the other is to make it so complicated that there are no OBVIOUS deficiencies Professor C. A. R. Hoare The 1980 Turing award lecture I think the one thing all should be able to agree on about systemd is that systemd falls into the latter. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/753535.36099...@smtp138.mail.ir2.yahoo.com
Re: goals for hardening Debian: ideas and help wanted
On Wed, 30 Apr 2014 18:33:56 +0200 Aaron Zauner wrote: It adds a lot of complexity for privacy benefit. Integrity is often muddled into security too. As far as I am concerned they can actually counter each other and are seperate entities. No they are not. Integrity should be part of your understanding of security. Basics of information security suggest confidentiality, integrity and availability. [0] Suggested Basics, yes and good to remember they may influence each other but I don't like mixing them up once that is understood personally. The desired level of Information security *may* have next to nothing to do with integrity and conversely availability can often be everything in a specific situation. It makes much more practical sense to keep integrity and availability as their own seperate entities. All too often the word secure is confused and abused or marketed. All too often I have witnessed it being said that X is more secure when actually it may be more exploitable but increases availability or integrity. Debian developers not being able to upload security fixes is part of the mix but then I would guess you could more easily bring down the TOR network too than a private VPN and filtering would be much more difficult so I would say TOR is not *optimum* for security or availability and obscurity is no real security though perhaps very occasionally the best possible ;-). Obscuring from targetted attack is highly questionable to me when a secure VPN from a lightly used machine (no web browsing) can offer real security. You may just be giving a way in otherwise. First I don't understand your first sentence. Second how does a VPN provide more security than say Tor? Tor is more complex, less proven, had more past exploits and crucially I believe? generally more reliant on external infrastructure. It's primary aim is privacy and not a simply secure protocol. I include SSH when I say VPN too but host security is paramount in any case. Devs avoiding html mail clients on machines with keys or access etc.. might be another idea. Was there a resolution on binary uploads? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/483967.32253...@smtp150.mail.ir2.yahoo.com
Re: goals for hardening Debian: ideas and help wanted
On Tue, Apr 29, 2014 at 11:24:19AM +0100, Kevin Chadwick wrote: previously on this list people contributed: - easy create and run programs from chroot and alternate users Could you detail what you mean by this? It sounds like you want either virtual machines or something like docker.io: https://packages.debian.org/sid/docker.io hint: chroot $CHROOT_PATH su - $USER -c $command_with_args Security and chroots aren't things I would associate, you need better. A wide misconception. Chroots are easily implemented and add security almost for free Not completely for free. You now have an extra mini-system to maintain. (often /dev/log is all that is needed) and so can be used by default without any potential problems, they also never bring new risks unless you forget to unpdate them. It's also worth mentioning systemd-nspawn: http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html -- Tzafrir Cohen | tzaf...@jabber.org | VIM is http://tzafrir.org.il || a Mutt's tzaf...@cohens.org.il || best tzaf...@debian.org|| friend -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140502044104.gi2...@lemon.cohens.org.il
Re: goals for hardening Debian: ideas and help wanted
On Tue, 29 Apr 2014, Jakub Wilk wrote: A wide misconception. Chroots are easily implemented and add security ^^^ almost for free (often /dev/log is all that is needed) and so can be used by default without any potential problems, they also never bring new risks ^^^ and always make life difficult for an attacker to raise priviledges or get ^^ Bwahahahahahahahahahahahahahahahahahaha! Do you also laugh at people who enable hardening complier flags? I’ve pointed out above a few reasons here. My criticism is not by adding chroot as just another hurdle for any potential attackers, but with trying to sell chroot as security feature. This also does bring the new risk that people think “it uses chroot so it must be sure”. Really, there is no magic cure-everything in security. bye, //mirabilos -- [16:04:33] bkix: veni vidi violini [16:04:45] bkix: ich kam, sah und vergeigte... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.10.1404301438210.12...@tglase.lan.tarent.de
Re: goals for hardening Debian: ideas and help wanted
Kevin Chadwick wrote: I'm confused, what? How does Tor lower security and at the same time, it provides privacy? Just like antivirus scanners bring greater exploitability especially if you are not vulnerable to detectable viruses then so does Tor. What?! I don't even,.. It adds a lot of complexity for privacy benefit. Integrity is often muddled into security too. As far as I am concerned they can actually counter each other and are seperate entities. No they are not. Integrity should be part of your understanding of security. Basics of information security suggest confidentiality, integrity and availability. [0] Obscuring from targetted attack is highly questionable to me when a secure VPN from a lightly used machine (no web browsing) can offer real security. You may just be giving a way in otherwise. First I don't understand your first sentence. Second how does a VPN provide more security than say Tor? Deeply confused, Aaron [0] - https://en.wikipedia.org/wiki/Information_security signature.asc Description: OpenPGP digital signature
Re: goals for hardening Debian: ideas and help wanted
On Tue, Apr 29, 2014 at 11:35:26AM +0800, Paul Wise wrote: On Tue, Apr 29, 2014 at 8:07 AM, Marko Randjelovic wrote: - security patches should be clearly marked as such in every *.patch file That sounds like a good idea, could you add it to the wiki page? It's not always easy to say wether a patch is security relevant but for the obvious ones (e.g. those with a CVE assigned) I put them into debian/patches/security and noticed other packages doing the same. This makes it simple to distinguish them in i.e. gitweb without having to look into every patch for the DEP-3 header. Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140429065533.ga3...@bogon.m.sigxcpu.org
Re: goals for hardening Debian: ideas and help wanted
On Tue, 29 Apr 2014 11:35:26 +0800 Paul Wise p...@debian.org wrote: On Tue, Apr 29, 2014 at 8:07 AM, Marko Randjelovic wrote: - security patches should be clearly marked as such in every *.patch file That sounds like a good idea, could you add it to the wiki page? I added this: Debian policy should require that in every source package all security packages should be clearly marked as such in standard and easily parsable way with optional further references. - easy create and run programs from chroot and alternate users Could you detail what you mean by this? It sounds like you want either virtual machines or something like docker.io: https://packages.debian.org/sid/docker.io Cencerely, I never heard about Docker before, I didn't mean about VMs and I meant about chrooting. 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 - apt-get should automaticaly check checksums That happens now, if you find an instance where it does not, please file a severity serious bug report on apt with enough detail for the maintainers to debug and fix it. https://www.debian.org/Bugs/Reporting I didn't know it, does apt-get/aptitude/synaptic do complete checks? 1. verify Release file signature 2. verify checksums of repo files 3. verify checksums of individual .deb files I remmember some time ago I edited a file with hexedit (after apt-get downloaded it) and tried to install it with apt-get and it didn't complain. -- http://markorandjelovic.hopto.org One should not be afraid of humans. Well, I am not afraid of humans, but of what is inhuman in them. Ivo Andric, Signs near the travel-road -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014042910.73003...@eunet.rs
Re: goals for hardening Debian: ideas and help wanted
On Tue, Apr 29, 2014 at 4:22 PM, Marko Randjelovic wrote: Cencerely, I never heard about Docker before, I didn't mean about VMs and I meant about chrooting. 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 Security and chroots aren't things I would associate, you need better. I didn't know it, does apt-get/aptitude/synaptic do complete checks? 1. verify Release file signature 2. verify checksums of repo files 3. verify checksums of individual .deb files I expect so. I remmember some time ago I edited a file with hexedit (after apt-get downloaded it) and tried to install it with apt-get and it didn't complain. That sounds like possibly a bug but if you have an attacker able to modify files in /var/cache/apt/archives/ you have bigger problems I expect. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6ff_cezlqr5otpafw6bnwcskrt_sr81kke18cphndh...@mail.gmail.com
Re: goals for hardening Debian: ideas and help wanted
* Jacob Appelbaum ja...@appelbaum.net, 2014-04-29, 00:20: On 4/25/14, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: Tor provides privacy and more likely lowers security so which threat against contributors or contributor actions is the Tor policy aimed to protect? I'm confused, what? How does Tor lower security and at the same time, it provides privacy? Regarding lowered security, I guess Kevin might be referring to this: http://www.cs.kau.se/philwint/spoiled_onions/ The attackers don't have to know who they attack. Some men just want to watch the world burn. : So I don't see contradiction between privacy and lowered security. If you do, please enlighten us. :) -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140429095807.ga1...@jwilk.net
Re: goals for hardening Debian: ideas and help wanted
previously on this list people contributed: - easy create and run programs from chroot and alternate users Could you detail what you mean by this? It sounds like you want either virtual machines or something like docker.io: https://packages.debian.org/sid/docker.io hint: chroot $CHROOT_PATH su - $USER -c $command_with_args Security and chroots aren't things I would associate, you need better. A wide misconception. Chroots are easily implemented and add security almost for free (often /dev/log is all that is needed) and so can be used by default without any potential problems, they also never bring new risks and always make life difficult for an attacker to raise priviledges or get what they are actually after when done correctly. Even at a simple level it should be obvious that they can just nullify the payload so the attacker simply goes elsewhere. Does debian chroot unbound and nginx under their own unbound and nginx users by default? MACs are hardly ever used by default due to management problems and when they are they either may even lead to exploitable programs that cannot do what they expect to be able to or may not offer the protection expected and why not use the chroot under a MAC anyway. If the kernel can be attacked from the chroot then likely the MAC can and due to increased complexity, arguments just as easily arise against both. For most daemons where the filesystem access amounts to little then a MAC is unlikely to prevent any more attacks that chroot wouldn't and where a program needs a lot of access you are fighting a losing battle and you should rethink your attack surface. Time would be better spent on privsep or getting your web content to run without www-data writes via DACs than tuning a complicated MAC to allow it to some degree or writing a cgi program to keep things out of the chroot. What I am saying is MACs are fine when done right and you have the spare time but should not trump better design or excuse lack of priviledge seperation or the often underused and mis-understood power of DACs not being used to their upmost in the first place. Virtual machines add complexity, waste resources and cannot be on by default for each package which is very important. Also many new attacks like timing attacks between virtual machines arrive. Auditing and bug reporting is also greatly complicated compared to bare metal. I am interested in finding out more about qubes though if I find the time for the desktop, mainly in terms of how deep they may have gone for sandboxing say a browser. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/686939.12569...@smtp141.mail.ir2.yahoo.com
Re: goals for hardening Debian: ideas and help wanted
On Tue, 29 Apr 2014 00:20:05 + Jacob Appelbaum wrote: Tor provides privacy and more likely lowers security so which threat against contributors or contributor actions is the Tor policy aimed to protect? I'm confused, what? How does Tor lower security and at the same time, it provides privacy? Just like antivirus scanners bring greater exploitability especially if you are not vulnerable to detectable viruses then so does Tor. It adds a lot of complexity for privacy benefit. Integrity is often muddled into security too. As far as I am concerned they can actually counter each other and are seperate entities. Security is an application specific process to be understood in light of a particular threat model. So Tor for certain things yes but not for everything. Obscuring from targetted attack is highly questionable to me when a secure VPN from a lightly used machine (no web browsing) can offer real security. You may just be giving a way in otherwise. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/400899.24381...@smtp140.mail.ir2.yahoo.com
Re: goals for hardening Debian: ideas and help wanted
Marko Randjelovic markoran at eunet.rs writes: On Tue, 29 Apr 2014 11:35:26 +0800 Paul Wise pabs at debian.org wrote: On Tue, Apr 29, 2014 at 8:07 AM, Marko Randjelovic wrote: - security patches should be clearly marked as such in every *.patch file That sounds like a good idea, could you add it to the wiki page? I added this: Debian policy should require that in every source package all security packages should be clearly marked as such in standard and easily parsable way with optional further references. Veto because the security impact of bugs is disputable, and probably 100% of all patches: http://www.insanitybit.com/2012/06/02/linus-torvalds-all-bugs-are-created- equal-9/ bye, //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/loom.20140429t172650-...@post.gmane.org
Re: goals for hardening Debian: ideas and help wanted
Kevin Chadwick ma1l1ists at yahoo.co.uk writes: Security and chroots aren't things I would associate, you need better. A wide misconception. Chroots are easily implemented and add security almost for free (often /dev/log is all that is needed) and so can be used by default without any potential problems, they also never bring new risks and always make life difficult for an attacker to raise priviledges or get what they are actually after when done correctly. Even at a simple level it should be obvious that they can just nullify the payload so the attacker simply goes elsewhere. Does Bwahahahahahahahahahahahahahahahahahaha! (To casual observers: the entire paragraph is very wrong.) Yes, chroots help isolating things, but, just like systrace(4), they are far from being inescapable. bye, //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/loom.20140429t173408-...@post.gmane.org
Re: goals for hardening Debian: ideas and help wanted
previously on this list Thorsten Glaser contributed: Debian policy should require that in every source package all security packages should be clearly marked as such in standard and easily parsable way with optional further references. Veto because the security impact of bugs is disputable, and probably 100% of all patches: http://www.insanitybit.com/2012/06/02/linus-torvalds-all-bugs-are-created- equal-9/ ? Doesn't that page argue against your 'veto'? I can understand Linus not wanting to have to decide if there is any security relevence in each change or be accused of missing some when he of course would especially when he has said he can't keep up with the many commits and so must want to accelerate and not decelerate the process. I used to look through the commits when I could in order to decide whether to update the kernel more often than every other release and whilst some were obvious or even mentioned security I wondered what level of collaboration went on between distros to work out which had security implications or whether seperate processes helped spot more or not and just created more work. In any case once publicly known and sooner the better it is surely better to inform at every opportunity. p.s. Security is never black and white and I hate the same people, funny that, like reading your stars. There is lots of mis-information and lies about OpenBSD out there. I notice the page doesn't disclose any of his supposed findings or say very much at all. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/406410.91532...@smtp109.mail.ir2.yahoo.com
Re: goals for hardening Debian: ideas and help wanted
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 -- http://markorandjelovic.hopto.org One should not be afraid of humans. Well, I am not afraid of humans, but of what is inhuman in them. Ivo Andric, Signs near the travel-road -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140429184222.3296b...@eunet.rs
Re: goals for hardening Debian: ideas and help wanted
previously on this list Thorsten Glaser contributed: A wide misconception. Chroots are easily implemented and add security almost for free (often /dev/log is all that is needed) and so can be used by default without any potential problems, they also never bring new risks and always make life difficult for an attacker to raise priviledges or get what they are actually after when done correctly. Even at a simple level it should be obvious that they can just nullify the payload so the attacker simply goes elsewhere. Does Bwahahahahahahahahahahahahahahahahahaha! (To casual observers: the entire paragraph is very wrong.) Yes, chroots help isolating things, but, just like systrace(4), they are far from being inescapable. I also said the following and nothing is inescapable atleast in any general conversation, so who is being black and white now! Chroot provides a noticeable improvement in security at a very low cost in time to implement and almost 0 maintenance. Systrace has security merit too despite it's shortcomings at isolating ROOT in CERTAIN SITUATIONS and is used by sshd now by default. If the kernel can be attacked from the chroot then likely the MAC can and due to increased complexity, arguments just as easily arise against both. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/80183.89090...@smtp103.mail.ir2.yahoo.com
Re: goals for hardening Debian: ideas and help wanted
Marko Randjelovic marko...@eunet.rs writes: I added this: Debian policy should require that in every source package all security packages should be clearly marked as such in standard and easily parsable way with optional further references. I don't agree with this statement. I think there are far more important things to document in Policy that haven't yet been documented there than creating new rules about patch naming. Note that, currently, Debian Policy doesn't require that you use separated patches *at all*, nor should it given that there is not project consensus for requiring that source package representation. I'm fine with putting such a guideline somewhere advisory, such as the Developer's Reference, but I don't think Policy is the document you're looking for. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8738gwgk4q@windlord.stanford.edu
Re: goals for hardening Debian: ideas and help wanted
* Thorsten Glaser t...@debian.org, 2014-04-29, 15:35: A wide misconception. Chroots are easily implemented and add security almost for free (often /dev/log is all that is needed) and so can be used by default without any potential problems, they also never bring new risks and always make life difficult for an attacker to raise priviledges or get what they are actually after when done correctly. Even at a simple level it should be obvious that they can just nullify the payload so the attacker simply goes elsewhere. Does Bwahahahahahahahahahahahahahahahahahaha! Do you also laugh at people who enable hardening complier flags? Security is not black and white. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140429170215.gb4...@jwilk.net
Re: goals for hardening Debian: ideas and help wanted
On Tue, April 29, 2014 18:45, Russ Allbery wrote: Marko Randjelovic marko...@eunet.rs writes: I added this: Debian policy should require that in every source package all security packages should be clearly marked as such in standard and easily parsable way with optional further references. I don't agree with this statement. I think there are far more important things to document in Policy that haven't yet been documented there than creating new rules about patch naming. Note that, currently, Debian Policy doesn't require that you use separated patches *at all*, nor should it given that there is not project consensus for requiring that source package representation. I'm quite unclear even on what problem it tries to solve. Debian already extensively tracks which vulnerabilities affect which package versions, and I don't see what sorting patches into 'security' and 'other' would add to this. Thijs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21d2a0ee1c0575779cf73790ee5d5d2b.squir...@aphrodite.kinkhorst.nl
Re: goals for hardening Debian: ideas and help wanted
previously on this list Marko Randjelovic contributed: 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? Fair enough but almost all of those escape mitigations combat an attacker with ROOT priviledges and you shouldn't have been running the daemon as root in the first place and what is not in the chroot makes raising priviledges to root much more difficult. Chroot *IS* a security feature as extensively used by dovecot including priv sep and coded into sshd and unbound and apache and nginx. People *HAVE* watched attackers get frustrated and leave. The first thing an attacker usually tries with an exploit is to load /bin/sh then they may try to get data into the filesystem but find the filesystem is noexec and likely not writable by the process owner. Then all of a sudden especially with ASLR and a nonexec stack things have gotten much more difficult and the chances of causing noticeable crashes increases. At this point if they haven't left already, two things are likely to happen, if it is non targeted as the kernel.org attack was they leave and find one of the many other systems to attack. If it is a buy and shoot attack it has failed to execute the buyers shell code or program and your just one more system that isn't on their botlist. Otherwise they have a more difficult task of exploring the process space and attacking the kernel or hoping the chroot is not owned by root or the cd was not invoked. Chroot also helps to prevent MAC bypass on systems where grsec prvi I/O is not disabled. The whole point is security is layers and in my opinion MAC should be the final layer but many distro's and more so Fedora than debian use it whilst ignoring their lax DAC permissions. I thought this would be a no-brainer default atleast for some packages. I guess I was wrong? -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/450827.54193...@smtp120.mail.ir2.yahoo.com
Re: goals for hardening Debian: ideas and help wanted
Le mardi 29 avril 2014 à 15:35 +, Thorsten Glaser a écrit : A wide misconception. Chroots are easily implemented and add security almost for free Bwahahahahahahahahahahahahahahahahahaha! (To casual observers: the entire paragraph is very wrong.) Maybe you should go read a book or two on defense-in-depth before making such a fool of yourself… almost for free. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1398805595.5667.5.ca...@kagura.malsain.org
Re: goals for hardening Debian: ideas and help wanted
On Thu, 24 Apr 2014 10:57:39 +0800 Paul Wise p...@debian.org wrote: Hi all, I have written a non-exhaustive list of goals for hardening the Debian distribution, the Debian project and computer systems of the Debian project, contributors and users. https://wiki.debian.org/Hardening/Goals If you have more ideas, please add them to the wiki page. If you have more information, please add it to the wiki page. If you would like to help, please choose an item and start work. - security patches should be clearly marked as such in every *.patch file - easy create and run programs from chroot and alternate users - apt-get should automaticaly check checksums -- http://markorandjelovic.hopto.org One should not be afraid of humans. Well, I am not afraid of humans, but of what is inhuman in them. Ivo Andric, Signs near the travel-road -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140429020744.26376...@eunet.rs
Re: goals for hardening Debian: ideas and help wanted
On 4/25/14, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: previously on this list Paul Wise contributed: I have written a non-exhaustive list of goals for hardening the Debian distribution, the Debian project and computer systems of the Debian project, contributors and users. https://wiki.debian.org/Hardening/Goals If you have more ideas, please add them to the wiki page. ... Tor provides privacy and more likely lowers security so which threat against contributors or contributor actions is the Tor policy aimed to protect? I'm confused, what? How does Tor lower security and at the same time, it provides privacy? All the best, Jacob -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAFggDF14P25ZrOp3Yj=nfvaydtry+rnbcxgfdw-vvvrbvdf...@mail.gmail.com
Re: goals for hardening Debian: ideas and help wanted
On Tue, Apr 29, 2014 at 8:07 AM, Marko Randjelovic wrote: - security patches should be clearly marked as such in every *.patch file That sounds like a good idea, could you add it to the wiki page? - easy create and run programs from chroot and alternate users Could you detail what you mean by this? It sounds like you want either virtual machines or something like docker.io: https://packages.debian.org/sid/docker.io - apt-get should automaticaly check checksums That happens now, if you find an instance where it does not, please file a severity serious bug report on apt with enough detail for the maintainers to debug and fix it. https://www.debian.org/Bugs/Reporting -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6fk8+7x-hrhnv-+jhn2yrnkouobgzy6c7hsg5e3oze...@mail.gmail.com
Re: goals for hardening Debian: ideas and help wanted
On Thu, Apr 24, 2014 at 9:49 AM, Giacomo Mulas giacomo.mula...@gmail.com wrote: On Thu, 24 Apr 2014, Steve Langasek wrote: The apparmor policies in Debian apply a principle of minimal harm, confining only those services for which someone has taken the time to verify the correct profile. There are obviously pros and cons to each approach to MAC, which I'm not interested in arguing about; but one of the pros of the approach taken for apparmor is that all software *does* continue to work out of the box. If you found it otherwise, I think you should be filing a bug report against apparmor. Good to know, actually I had tried apparmor quite some time ago and did not try again. I will give it another spin as soon as I can. However, I do not agree that I should file bugs against apparmor if a debian package does not work properly, it should go to the package manager (and maybe cc to some apparmor expert team). It cannot be the maintainer(s) of apparmor to have to shoulder the effort of creating and maintaining profiles for all debian packages. They may be called in for support, but regular package maintainers should be involved IMHO, otherwise it will never really take off and provide significantly better security. Both of you have misunderstood each other. Steve, Giacomo was advocating the creation of profiles/configurations for all debian packages and considering it a serious bug if that was not done. Giacomo, Steve thought that you meant that unconfined applications should work perfectly when the user is using a MAC, and not that they should integrate with the MAC mechanism. So he was trying to explain how AppArmor only interferes with explicitly configured (by the package maintainer or user) profiles, and would not cause any harm to non-confined applications. This is forgivably irrelevant, because you are talking about confined applications. Best regards, -- Cameron Norman -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/calzwfrlhuawxatvzeb46jbuvozm54crpxac0ksx_wajx4pd...@mail.gmail.com
Re: goals for hardening Debian: ideas and help wanted
previously on this list Paul Wise contributed: I have written a non-exhaustive list of goals for hardening the Debian distribution, the Debian project and computer systems of the Debian project, contributors and users. https://wiki.debian.org/Hardening/Goals If you have more ideas, please add them to the wiki page. Though it will take some guts, the best way I see for a distro to help users secure their machines is to provide sudoers entries disabled by default and enabled either manually through requests during various package installs or a sudoers-policies package or in sudoers.d by default. I've read a story about sudoers being packaged by distro's at one time but mistakes meaning they stopped doing so. I expect that's a myth and silly if not. I find little about it but hearsay and whilst I know sudo's maintainer prefers rules not to be enabled by default as that encourages general policies and so an insecure default. I am not sure he minds commented policies that are easily enabled. If I ever have any time I intend to create a sudoers policy site if no-one beats me to it and more searches don't find one but a project like debian may be better suited to the task. Sudo is undoubtedly more secure than polkit when used correctly and easily modified by users. If things like synaptic had an option to use sudo, users could very easily and intuitively modify the default policy to only allow a certain list of packages to be installed and synaptic would be none the wiser and work very securely with whatever exact permissions the user decides and that apt-get provides the control for. This empowers users and the more correct way of doing things. Any security related tools and settings should have a high quality man page. All security configuration should be insisted on being in /etc if it isn't already. A default polkit configuration for example should be easily found and edited and not be allowed to exist in /usr or need to be copied from anywhere to anywhere. That is simply irresponsible. sysctl.conf could perhaps have more commented entries If a doc exists in /usr/share then perhaps a man page should atleast point to it and be found via apropos in many cases as understanding is the first step to securing. You could port the privledge seperation patches for X11 from OpenBSD so that only a small part for handling device files etc. runs as root. tcpdump is more secure but for more risky things like wireshark it could be made to die perhaps by a wrapper if run as root and dumpcap be suid group wireshark mode 750 and users add themselves to that group to use it. http://marc.info/?l=openbsd-miscm=139694935227588w=2 More use of chrooting by default would be good too. Some comments on the existing content on the page follows. Tor provides privacy and more likely lowers security so which threat against contributors or contributor actions is the Tor policy aimed to protect? Asking contributor's to boot debian where possible without listening services from dedicated usb/hdd with a vpn or ssh to avoid router resident attackers maybe seen as a bit draconian but I would suggest is a better practice to aim for. If grsec is coming RBAC deserves mentioning under MACs Routers, you could simplify their usage so you are using a subset of the firmware risk. So use bridge mode and a pppoe client on a debian or an OpenBSD box where I can contest pppoe setup is dead easy and in kernel. Though the bastille debian box and VPN two paragraphs up is probably easier for most with wireless etc. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/246269.70707...@smtp101.mail.ir2.yahoo.com
Re: goals for hardening Debian: ideas and help wanted
Apologies for the top posting, I'm writing this from my phone. I get a 403 when trying to access via Orbot/Orweb on Android 4.1 phone. Amusing. Lesley On 24 Apr 2014 03:58, Paul Wise p...@debian.org wrote: Hi all, I have written a non-exhaustive list of goals for hardening the Debian distribution, the Debian project and computer systems of the Debian project, contributors and users. https://wiki.debian.org/Hardening/Goals If you have more ideas, please add them to the wiki page. If you have more information, please add it to the wiki page. If you would like to help, please choose an item and start work. -- bye, pabs http://wiki.debian.org/PaulWise
Re: goals for hardening Debian: ideas and help wanted
On 10:57 Thu 24 Apr 2014, Paul Wise wrote: ..[snip].. https://wiki.debian.org/Hardening/Goals Regarding the line (at that page): Refuse to install packages that are known to have X number of unplugged exploits (i.e. X number of open security bugs in the bug tracker) unless e.g. --allow-vulnerable-packages is used. This makes it clear that you are installing software that is vulnerable. I suggest it might be better if exploits were each given a quick/approximate ranking in terms of severity (and if the severity is unknown it could be assigned a default median ranking), so that the algorithm you mention wouldn't just add number of unplugged exploits, but add them by weight. For example: the recent heartbleed exploit would be worth more than a few smaller exploits in less critical software, and would be calculated as such... -- PGP fingerprint: BB0A 0787 C0EE BDD8 7F97 3D30 49F2 13A5 265D CCBD -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140424080627.GB31307@hernia
Re: goals for hardening Debian: ideas and help wanted
On Jo, 24 apr 14, 11:06:27, Rowan Thorpe wrote: On 10:57 Thu 24 Apr 2014, Paul Wise wrote: ..[snip].. https://wiki.debian.org/Hardening/Goals Regarding the line (at that page): Refuse to install packages that are known to have X number of unplugged exploits (i.e. X number of open security bugs in the bug tracker) unless e.g. --allow-vulnerable-packages is used. This makes it clear that you are installing software that is vulnerable. I suggest it might be better if exploits were each given a quick/approximate ranking in terms of severity (and if the severity is unknown it could be assigned a default median ranking), so that the algorithm you mention wouldn't just add number of unplugged exploits, but add them by weight. For example: the recent heartbleed exploit would be worth more than a few smaller exploits in less critical software, and would be calculated as such... Bug severities are probably enough for this purpose. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: goals for hardening Debian: ideas and help wanted
I suggest it might be better if exploits were each given a quick/approximate ranking in terms of severity (and if the severity is unknown it could be assigned a default median ranking), so that the algorithm you mention wouldn't just add number of unplugged exploits, but add them by weight That is a good idea. The Common Vulnerability Scoring System was invented for this purpose: http://en.wikipedia.org/wiki/CVSS Kind regards, Richard -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/7f6371fd-0ee0-4f36-8f36-7736f65e7...@vdberg.org
Re: goals for hardening Debian: ideas and help wanted
On Thu, 24 Apr 2014, Paul Wise wrote: On Thu, 2014-04-24 at 02:53 -0007, Cameron Norman wrote: Would the inclusion of more AppArmor profiles be applicable? Thanks, added along with SELinux/etc. I second that. Actually, some time ago I tried using both AppArmor and SELinux, but gave up because it took forever to find legitimate behaviour of all kinds of common packages (most of them standard debian packages) and prepare configuration files for things to work. If debian wants to foster adoption of such security enhancements, it must go to great lengths in making sure that (in order of importance in my humble opinion) 1) all debian-packaged software works (very nearly) out of the box with debian-supported MAC frameworks. It should be very clear that if they don't it's an important bug that needs fixing. For example, such bugs should prevent the inclusion of a package in an official stable release. Or split the main debian archive in two, one that is MAC-ready and one that is not, so each user can decide to only use packages known to work well with debian-supported MAC frameworks. 2) for each debian-supported MAC framework there should be an expert team which should a) help package maintainers learn how to create and include appropriate configuration files so that their package works with the MAC framework b) create some tools (debhelper-like?) to make it relatively easy to find the minimum access rights a package needs and implement them in a configuration file c) define appropriate style guidelines to make configuration files as readable and maintainable as possible. All of this is going to be a lot of work at the beginning, but it will quickly decrease as more and more package maintainers get familiar with MAC frameworks. 3) there should be a category of packages in contrib which just contain configuration files for commonly used non-free software. Such configuration files should be audited by the appropriate expert teams before acceptance, to make sure they do not grant unnecessary access privileges. Until at very least point 1) is fulfilled, I doubt there will be widespread adoption of MAC frameworks, except for very specialised systems for which the amount of effort in setting them up is limited. General purpose computers (i.e. the ones in a pool of computers available for PhD students at a University, which must have a lot of packages installed for general use) will remain out of the question. Bye Giacomo -- _ Giacomo Mulas gmu...@oa-cagliari.inaf.it _ INAF - Osservatorio Astronomico di Cagliari via della scienza 5 - 09047 Selargius (CA) tel. +39 070 71180244 mob. : +39 329 6603810 _ When the storms are raging around you, stay right where you are (Freddy Mercury) _ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.10.1404241121540.8...@capitanata.oa-cagliari.inaf.it
Re: goals for hardening Debian: ideas and help wanted
On Thu, Apr 24, 2014 at 11:45:46AM +0200, Giacomo Mulas wrote: On Thu, 24 Apr 2014, Paul Wise wrote: Would the inclusion of more AppArmor profiles be applicable? Thanks, added along with SELinux/etc. I second that. Actually, some time ago I tried using both AppArmor and SELinux, but gave up because it took forever to find legitimate behaviour of all kinds of common packages (most of them standard debian packages) and prepare configuration files for things to work. If debian wants to foster adoption of such security enhancements, it must go to great lengths in making sure that (in order of importance in my humble opinion) 1) all debian-packaged software works (very nearly) out of the box with debian-supported MAC frameworks. It should be very clear that if they don't it's an important bug that needs fixing. For example, such bugs should prevent the inclusion of a package in an official stable release. Or split the main debian archive in two, one that is MAC-ready and one that is not, so each user can decide to only use packages known to work well with debian-supported MAC frameworks. The apparmor policies in Debian apply a principle of minimal harm, confining only those services for which someone has taken the time to verify the correct profile. There are obviously pros and cons to each approach to MAC, which I'm not interested in arguing about; but one of the pros of the approach taken for apparmor is that all software *does* continue to work out of the box. If you found it otherwise, I think you should be filing a bug report against apparmor. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: goals for hardening Debian: ideas and help wanted
On Thu, 24 Apr 2014, Steve Langasek wrote: The apparmor policies in Debian apply a principle of minimal harm, confining only those services for which someone has taken the time to verify the correct profile. There are obviously pros and cons to each approach to MAC, which I'm not interested in arguing about; but one of the pros of the approach taken for apparmor is that all software *does* continue to work out of the box. If you found it otherwise, I think you should be filing a bug report against apparmor. Good to know, actually I had tried apparmor quite some time ago and did not try again. I will give it another spin as soon as I can. However, I do not agree that I should file bugs against apparmor if a debian package does not work properly, it should go to the package manager (and maybe cc to some apparmor expert team). It cannot be the maintainer(s) of apparmor to have to shoulder the effort of creating and maintaining profiles for all debian packages. They may be called in for support, but regular package maintainers should be involved IMHO, otherwise it will never really take off and provide significantly better security. Thanks for the information. Giacomo -- _ Giacomo Mulas gmu...@oa-cagliari.inaf.it _ INAF - Osservatorio Astronomico di Cagliari via della scienza 5 - 09047 Selargius (CA) tel. +39 070 71180244 mob. : +39 329 6603810 _ When the storms are raging around you, stay right where you are (Freddy Mercury) _ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.10.1404241841420.15...@capitanata.oa-cagliari.inaf.it
Re: goals for hardening Debian: ideas and help wanted
El Wed, 23 de Apr 2014 a las 7:57 PM, Paul Wise p...@debian.org escribió: Hi all, I have written a non-exhaustive list of goals for hardening the Debian distribution, the Debian project and computer systems of the Debian project, contributors and users. https://wiki.debian.org/Hardening/Goals If you have more ideas, please add them to the wiki page. If you have more information, please add it to the wiki page. If you would like to help, please choose an item and start work. Would the inclusion of more AppArmor profiles be applicable? Thanks, -- Cameron Norman
Re: goals for hardening Debian: ideas and help wanted
On Thu, 2014-04-24 at 02:53 -0007, Cameron Norman wrote: Would the inclusion of more AppArmor profiles be applicable? Thanks, added along with SELinux/etc. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: goals for hardening Debian: ideas and help wanted
2014-04-24 4:57 GMT+02:00 Paul Wise p...@debian.org: Hi all, I have written a non-exhaustive list of goals for hardening the Debian distribution, the Debian project and computer systems of the Debian project, contributors and users. https://wiki.debian.org/Hardening/Goals If you have more ideas, please add them to the wiki page. If you have more information, please add it to the wiki page. If you would like to help, please choose an item and start work. -- bye, pabs http://wiki.debian.org/PaulWise What about challenging a bit more default packages regarding security/feature ? We had such a debate about exim but I guess we could have the same about bind and much more. -- Cordialement, Jean-Baptiste Boisseau Eutech SSII Tel : +33 3 25 81 29 65 Mob: +33 6 63 11 79 40 Fax : +33 9 56 21 06 96
