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-security-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-security-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-security-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
On Sat, Jun 7, 2014 at 11:07 AM, Tom Dial wrote: I suggest resumption of maintenance for OVAL to support OpenSCAP. www.debian.org/security/oval/ seems not to have been maintained since some time in late 2010 or early 2011. Please refer to https://bugs.debian.org/738199 If you would like to help out with fixing this, you can find the script in CVS: https://anonscm.debian.org/viewvc/webwml/webwml/english/security/oval/ -- bye, pabs http://wiki.debian.org/PaulWise -- 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/caktje6e9z02cdt0srkw4usqhh4fgu4veoomswilxzaozirn...@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-security-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
I suggest resumption of maintenance for OVAL to support OpenSCAP. www.debian.org/security/oval/ seems not to have been maintained since some time in late 2010 or early 2011. Tom Dial On 04/23/2014 08:57 PM, Paul Wise 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. -- 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/53928208.7070...@comcast.net
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-security-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-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140429122053.2c7a5...@eunet.rs
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
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/ In deed a Linux chroot - environment is not a jail. You could use sth. like grsecurity to harden Linux chroot environments; or any MAC (Mandatory Access) system like SELinux. You may also read a bit about the security of chroot at http://www.elstel.org/xchroot/ (the first two sections). -- 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/6da36cf6-1942-45b3-831f-4689d2021...@gmail.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-security-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
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: goals for hardening Debian: ideas and help wanted
On 24 Apr 2014 10:58, Andrew McGlashan andrew.mcglas...@affinityvision.com.au wrote: On 24/04/2014 5:49 PM, Lesley Binks wrote: 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. It works for me [Orbot/Orweb -- 4.3 on both i9300 and i9505], did you get the case right? Strangely though my i9300 wouldn't use Tor properly until I rebooted it; Orbot said it was fine, but Orweb gave my public IP address! It was fine after a reboot, but I don't know why that was necessary. Thanks Andrew Just retried the link in an Orbot/Orweb combo and the page came up okay. Kind regards Lesley
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-security-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 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-security-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-security-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
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-security-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
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-security-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 24/04/2014 5:49 PM, Lesley Binks wrote: 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. It works for me [Orbot/Orweb -- 4.3 on both i9300 and i9505], did you get the case right? Strangely though my i9300 wouldn't use Tor properly until I rebooted it; Orbot said it was fine, but Orweb gave my public IP address! It was fine after a reboot, but I don't know why that was necessary. Cheers A. -- 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/5358e019.7090...@affinityvision.com.au
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-security-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 24. huhtikuuta 2014 12.57.45 EEST, Andrew McGlashan andrew.mcglas...@affinityvision.com.au wrote: It works for me [Orbot/Orweb -- 4.3 on both i9300 and i9505], did you get the case right? wiki.d.o seems to be blocking at least some Tor exit nodes. IMHO it should not do that, at least for read-only access. -- 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/13fd383a-8c0b-4647-91fc-d3c73850b...@email.android.com
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-security-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
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
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
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
