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
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.
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?
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
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
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
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
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
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
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
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
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
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
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:
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
* 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
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
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
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
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
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
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
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
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
* 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
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.
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
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 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
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.
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
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.
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,
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
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.
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
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
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
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
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
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
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
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
43 matches
Mail list logo
