Re: Bits from the release team and request for discussion
On Wed, 26 Aug 2009, Manoj Srivastava sriva...@debian.org wrote:
if [ -e /etc/pam.d/login ]; then
perl -pli~ -e 'm/session.*pam_selinux.so/ s/^\#\s*//o'
/etc/pam.d/login rm /etc/pam.d/login~
fi
if [ -e /etc/pam.d/ssh ]; then
perl -pli~ -e 'm/session.*pam_selinux.so/ do { s/^\#\s*//o;
s/multiple//; } ' /etc/pam.d/ssh rm /etc/pam.d/ssh~
fi
I would prefer it if this sort of thing was kept to scripts
like /usr/sbin/selinux-activate from the selinux-basics package.
If you believe that selinux-activate is inadequate in some way then feel free
to file a bug report (or in the case of Manoj just do an upload to fix it).
In terms of documentation I think that perhaps comments in the
selinux-activate script would go a long way. Then the ideal advice would be
something like use selinux-activate, but if you want to do it your own
different way then read the comments and do whatever seems right.
As things change scripts like selinux-activate will change to match. But we
will keep them matching the current distribution.
I have no objection to anyone editing config files by hand, but I would prefer
that when offering advice such things be given a low priority.
--
russ...@coker.com.au
http://etbe.coker.com.au/ My Main Blog
http://doc.coker.com.au/ My Documents Blog
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bits from the release team and request for discussion
ond...@sury.org writes: with root being signed[1] really soon (TM), could we add DNSSEC support to this list? Since I have recently switched position in my company (which took a lot of time), it looks like I will have now plenty of time for DNSSEC (since I can put DNSSEC in Debian to my top priorities). What is needed to enable DNSSEC support in Debian? How many changes do we actually need to do? Have bugs been filed for this? Is there already documentation about this somewhere? We would be happy add this as a release goal, but I fear we simply don't know enough about it :-) Marc -- BOFH #300: Digital Manipulator exceeding velocity parameters pgpQsJBa4ABmb.pgp Description: PGP signature
Re: Bits from the release team and request for discussion
On Tue, Aug 25 2009, Luk Claes wrote:
Manoj Srivastava wrote:
Hi,
I would like to set up a selinux related release goal for
Squeeze.
Developer assiociated: Manoj Srivastava (Perhaps also Russell Coker,
but I have not discussed this with him)
Issues to be solved:
(a) Get all Debian patches to the reference security policy merged in
upstream. Status: In progress, we have all patches submitted,
some need to be tweaked and resubmitted based on feedback
Time line: 1-2 months, depending on free tie I have
While this is relevant to Debian, it does not look like it impacts what
is in Debian or are there possible changes in Debian depending on the
feedback?
I think there is a distinct possibility, yes. As the reference
policy evolves upstream, and out patches are not also changed to keep
in sync, we are reaching what I think are sublte breakages. The gbest
way of ensuring that we do not have mismatches in policy is to get the
patches into upstream policy, which has many more eyeballs on it, and
is tested more extensively.
(b) Update reference security policy to allow standard machines to be
in enforcing mode.
Status: It is possible to run minimal virtual machines in
enforcing mode, but real machines are somewhat crippled; these
denials need to be inspected, and determination needs to be made
for how to resolve them (no not want security holes enshrined in
policy)
Time line: 6-8 months (can be done in tandem with a, if here were
more people working on it)
Are the issues identified already or do you have an idea about how
many issues there are to tackle?
The issues involved depend on the set of packages
installed. Russell Coker has identified and solved issues related to
his play machine, and to his eepc laptop. My build machines which use
selinux virtual machine now show no issues, and most of the issue on my
development machine have been resolved.
I am uncertain of issues with SELinux and packages I do not
use. There are a few reported already against the refpolicy package,
and I am working at looking at them, and then forwarding them to the
refpolicy mailing list.
I am also somewhat rusty with the conventions adopted in
reference policy (some style issues, and some with more substance), so
this s likely to be slow going until I have time to get myself back up
to speed with modern policy. Help here is greatly appreciated.
Do you have any documentation for possible contributors to help you with
this?
I try this recipe (can be used in virtual machines, if you do
not want to mess up your real machines)
--8---cut here---start-8---
aptitude install --without-recommendsselinux-policy-default selinux-basics
if [ -e /etc/selinux/${UML_POLICY_TYPE}/contexts/files/file_contexts ]; then
setfiles /etc/selinux/default/contexts/files/file_contexts /
fi
if [ -e /etc/pam.d/login ]; then
perl -pli~ -e 'm/session.*pam_selinux.so/ s/^\#\s*//o' /etc/pam.d/login
rm /etc/pam.d/login~
fi
if [ -e /etc/pam.d/ssh ]; then
perl -pli~ -e 'm/session.*pam_selinux.so/ do { s/^\#\s*//o; s/multiple//;
} ' /etc/pam.d/ssh
rm /etc/pam.d/ssh~
fi
if which setfiles /dev/null 21; then
if [ -e /etc/selinux/${UML_POLICY_TYPE}/contexts/files/file_contexts ]; then
setfiles /etc/selinux/${UML_POLICY_TYPE}/contexts/files/file_contexts
/etc/pamd.d/
fi
fi
if [ -x /sbin/fixfiles ]; then
/sbin/fixfiles -l /root/fixfiles.log -f -F relabel
fi
# schedule a relabeling for the next reboot
touch /.autorelabel
--8---cut here---end---8---
To grub, I add:
--8---cut here---start-8---
# defoptions=selinux=1 audit=1
--8---cut here---end---8---
And then reboot. The next reboot will finish relabelling the
files, and sets me up with selinix enabled, and in enforcing mode.
If we had more people testing the SELinux policies and reporting
the denials to the refpolicy mailing list, we could rapidly get into
refpolicy in sync with Debian specific additions.
Thanks in advance for help,
manoj
--
Intelligence without character is a dangerous thing. Steinem
Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bits from the release team and request for discussion
Hi, On Sonntag, 2. August 2009, martin f krafft wrote: In the next announcement, I strongly suggest you approach this point. If you are syncing with Ubuntu LTS, then I suggest you state the reasons for doing so, e.g. that Canonical has agreed to provide security upgrades for squeeze). Oh, did they? Hope this helps, I dont think so. You made it sound as if Debian would follow Ubuntu or Marks wishes, and that Ubuntu/Canonical has committed to support Debian. AFAIK, we dont and they dont. regards, Holger signature.asc Description: This is a digitally signed message part.
Re: Bits from the release team and request for discussion
also sprach Holger Levsen hol...@layer-acht.org [2009.08.03.1047 +0200]: In the next announcement, I strongly suggest you approach this point. If you are syncing with Ubuntu LTS, then I suggest you state the reasons for doing so, e.g. that Canonical has agreed to provide security upgrades for squeeze). Oh, did they? That was just one possible outcome/example. Hope this helps, I dont think so. You made it sound as if Debian would follow Ubuntu or Marks wishes, and that Ubuntu/Canonical has committed to support Debian. AFAIK, we dont and they dont. I phrased it badly then. It's exactly points like this which need to be addressed explicitly: why are we doing this? And iff Canonical/Ubuntu is part of the reason, then state exactly where the benefits for Debian are, and ideally how this decision was reached in the first place. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems a fundamentalist is someone who hates sin more than he loves virtue. -- john h. schaar digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: Bits from the release team and request for discussion
On Thu, Jul 30, 2009 at 11:16 AM, Manoj Srivastavasriva...@debian.org wrote: Hi, I would like to set up a selinux related release goal for Squeeze. Developer assiociated: Manoj Srivastava (Perhaps also Russell Coker, but I have not discussed this with him) Issues to be solved: (a) Get all Debian patches to the reference security policy merged in upstream. Status: In progress, we have all patches submitted, some need to be tweaked and resubmitted based on feedback Time line: 1-2 months, depending on free tie I have (b) Update reference security policy to allow standard machines to be in enforcing mode. Status: It is possible to run minimal virtual machines in enforcing mode, but real machines are somewhat crippled; these denials need to be inspected, and determination needs to be made for how to resolve them (no not want security holes enshrined in policy) Time line: 6-8 months (can be done in tandem with a, if here were more people working on it) (c) Make it easier to run in struct (no unconfined.pp module) mode. This needs firstly documentation, and secondly, additional tweaks to policy to make it work. Russell has a play machine where it all works, but those changes are not in the reference policy -- and some of them might not be fit to be in ref policy at all. Time line: 9-12 months The actual non-policy packages are now well in sync with upstream, so the weak point is the security policy. Ideally, the goal would be to have Squeeze certifiable at EAL-4, at least the standard install (no optional packages), if someone with deep pockets were willing to actually pay for the certification, and be willing to push through the process. Which parts of the work you described above would be needed to Squeeze be certifiable at EAL-4? All of them? Based on your timeline, it seems A is on track to make Squeeze, we should get more people to work with you on B (setting as a goal) and C would be a no go for this release, jmo. Am I wrong? regards, -- Gustavo stratus Franco -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bits from the release team and request for discussion
Hi, I would like to set up a selinux related release goal for Squeeze. Developer assiociated: Manoj Srivastava (Perhaps also Russell Coker, but I have not discussed this with him) Issues to be solved: (a) Get all Debian patches to the reference security policy merged in upstream. Status: In progress, we have all patches submitted, some need to be tweaked and resubmitted based on feedback Time line: 1-2 months, depending on free tie I have (b) Update reference security policy to allow standard machines to be in enforcing mode. Status: It is possible to run minimal virtual machines in enforcing mode, but real machines are somewhat crippled; these denials need to be inspected, and determination needs to be made for how to resolve them (no not want security holes enshrined in policy) Time line: 6-8 months (can be done in tandem with a, if here were more people working on it) (c) Make it easier to run in struct (no unconfined.pp module) mode. This needs firstly documentation, and secondly, additional tweaks to policy to make it work. Russell has a play machine where it all works, but those changes are not in the reference policy -- and some of them might not be fit to be in ref policy at all. Time line: 9-12 months The actual non-policy packages are now well in sync with upstream, so the weak point is the security policy. Ideally, the goal would be to have Squeeze certifiable at EAL-4, at least the standard install (no optional packages), if someone with deep pockets were willing to actually pay for the certification, and be willing to push through the process. manoj -- The Public is merely a multiplied me. Mark Twain Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bits from the release team and request for discussion
On Thu, Jul 30, 2009 at 07:28:58PM +0200, Luk Claes wrote: Timeline Based on feedback of the community on the plan to freeze in December 2009 and the ambituous Release Goals we set for ourselves, we are revisiting the decision to freeze December 2009. We'll be consulting all key teams within Debian to see how their plans and schedules can fit into a new timeline. Before the end of August we hope to have finished this process of consultation and be able to present the new plan to you. Hi, Both Felix and I think that December as freeze date for GRUB is a bit too tight. For Squeeze we plan to make GRUB 2 the default, and it's not an easy migration. Nevertheless, if you decide to go with that, we'll try to accomodate. HTH -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bits from the release team and request for discussion
Le Thu, Jul 30, 2009 at 07:28:58PM +0200, Luk Claes a écrit : Timeline Based on feedback of the community on the plan to freeze in December 2009 and the ambituous Release Goals we set for ourselves, we are revisiting the decision to freeze December 2009. We'll be consulting all key teams within Debian to see how their plans and schedules can fit into a new timeline. Before the end of August we hope to have finished this process of consultation and be able to present the new plan to you. Dear release team, many thanks for revisiting your decision. It is much appreciated. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bits from the release team and request for discussion
On Fri, 31 Jul 2009, Manoj Srivastava sriva...@debian.org wrote: Developer assiociated: Manoj Srivastava (Perhaps also Russell Coker, but I have not discussed this with him) I will be involved in this, but I find it difficult to get enough free time. Issues to be solved: (a) Get all Debian patches to the reference security policy merged in upstream. Status: In progress, we have all patches submitted, some need to be tweaked and resubmitted based on feedback Time line: 1-2 months, depending on free tie I have Great work! (b) Update reference security policy to allow standard machines to be in enforcing mode. Status: It is possible to run minimal virtual machines in enforcing mode, but real machines are somewhat crippled; these denials need to be inspected, and determination needs to be made for how to resolve them (no not want security holes enshrined in policy) Time line: 6-8 months (can be done in tandem with a, if here were more people working on it) That shouldn't be difficult. Incidentally it would really help me with working on this if you could get the policy to build with -j2... (c) Make it easier to run in strict (no unconfined.pp module) mode. This needs firstly documentation, and secondly, additional tweaks to policy to make it work. Russell has a play machine where it all works, but those changes are not in the reference policy -- and some of them might not be fit to be in ref policy at all. Time line: 9-12 months My Play Machine runs the same policy as every other SE Linux machine I run which is also the same as the policy in my repository (a newer version than the policy in Lenny). There is a single extra module of policy which allows read-only and read-append file types so that guest users can't mess with each other so easily. The basic strict functionality works without any changes to policy. Solving B plus writing a tiny amount of documentation will solve C. Ideally, the goal would be to have Squeeze certifiable at EAL-4, at least the standard install (no optional packages), if someone with deep pockets were willing to actually pay for the certification, and be willing to push through the process. The EAL number is a matter of how well you meet your profile targets. We can meet the requirements to be certifiable (*) with CAPP and RBACPP at EAL-4 if we continue on the current course. Meeting LSPP will be a lot harder, I've never even tried that on Debian. Not that out users are likely to mind - very few people use LSPP configurations. (*) Getting certified requires a lot of time, paperwork, and money. Expect to spend the best part of $1,000,000 to get it. -- russ...@coker.com.au http://etbe.coker.com.au/ My Main Blog http://doc.coker.com.au/ My Documents Blog -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
