[redhat-lspp] LSPP Development Telecon 01/15/2007 Minutes

Loulwa Salem loulwas at us.ibm.com
Tue Jan 16 20:06:13 UTC 2007


01/15/2007 lspp Meeting Minutes:
===============================
   Attendees

   George Wilson (IBM) - GW
   Kris Wilson (IBM) - KEW
   Loulwa Salem (IBM) - LS
   Debora Velarde (IBM) - DV
   Michael Thompson (IBM) - MT
   Joy Latten (IBM) - JL
   Kylene J Hall (IBM) - KH
   Klaus Kiwi (IBM) - KK
   Irina Boverman (Red Hat) - IB
   Steve Grubb (Red Hat) - SG
   Dan Walsh (Red Hat) - DW
   Eric Paris (Red Hat) - EP
   Klaus Weidner (Atsec) - KW
   Chad Hanson (TCS) - CH
   Ted Toth - TT

Tentative Agenda:

Kernel / Beta / rawhide update
===============================
     GW: how is the current installation 01/05? I had an issue where I can't 	
	build policy modules
     DW: update to latest policy and should will fix it.
     GW: ok, that's great
     DW: I put the updated policy .27 on people page
     GW: thanks. I'm hacking on the self tests policy, and was trying to get
	audit to build modules correctly. Ok, so we need lspp.62 and policy
	package, anything else?
     SG: openssh I think also
     GW: that will pick up extended syntax
     SG: yes. I need to make scripts to pick up the updated packages to put in
	the repository. so I'll work on pulling the packages.
     DW: openssh.16 is up on people page. and klaus weidner put some notes and he
	tested it out.
     GW: great because we need that for the test cases.
     DW: scp works with that one as well.
     KW: you can use that if you are using labeled networking. Not sure what is
	happening but I was able to use that to select a level even not using
	the right xinetd. That is a security hole
     GW: that is a manual fix right?
     KW: yes, there is no way to do that with config
     GW: we'll document that very well then
     DW: it wouldn't know you are coming out of labeled network. that's the
	problem
     KW: yes. I think we need an xinetd patch to fix that. The problem is that it
	tries to get entire context and then gets confused. One thing that would 	help 
is changing default level for normal users to be classified other
	than systemlow
     GW: what would that default level be?
     KW: if people configure users to get an s1 level then this might go away
     DW: I have a feeling this can cause lots of problems
     KW: it needs testing
     GW: what if you can configure labels in xinetd config file, it still sounds
	dangerous
     KW: not sure if it is desirable, since you don't want to force everyone to
	use it. I think documentations solution is a good solution. unless we
	want to change that in xinetd.
     GW: kinda unpleasant to have to manually configure this
     SG: I don't think we have a problem to put patch in but it's getting late
	kinda. if we have to we will. I don't think there will be problem with
	xientd using a label. I think we need to create another parser for that
	which has to verify when daemon starts.
     GW: sounds like you need context string
     SG: per service or default?
     GW: sounds like per service and use it for ssh now
     KW: there is a config file for services anyways where you can put an option.
	you can add to that
     SG: it will be a separate configuration line. I think there are lots of
	people that prefer xientd take that from policy rather something admins
	configures
     KW: not sure policy is the appropriate place. in a sense it is something per
	service.
     SG: is this problem because get getcon is not working right
     KW: I didn't check where exactly it goes wrong, but now it is a problem when
	using the label flag
     SG: wondering if third parties expect getcon to function.
     KW: I think in a way that should be decided for admin. pretending something
	is coming at a certain level would be unsafe
     SG: I wonder if there is libselinux lib call to use. somehow I want to think
	it wants to be controlled by policy so people can do information flow
	analysis. if you take it out of policy then there won't be one file
	people can use for information flow analysis.
     KW: not sure this is a policy issue, there is no info to base policy
	decision on. also applications must differentiate between the labels. if	 
getcon returns label, and if it had no info, it would be wrong thing to
	do
     DW: getfilecon is an example. I take it back, I think it returns nothing.
     SG: Wasn't there a requirement where admin has to do auditable config change
	to allow imports or exports
     GW: yeah that is a requirement. you wouldn't be auditing at that level of
	granularity but you would be still auditing
     SG: we were counting on changecon to do that.
     GW: requirement is that it is auditable
     KW: if it is a known routine, it doesn't' need to be auditable if it only
	happens once
     SG: wondering if we make a change in xinetd it sounds it falls in the
	import/export section
     GW: it still follows requirement. just not with granularity
     SG: there is no program to configure xinetd
     GW: but you can place watch on the file .. right?
     SG: but in the past, placing a watch is not sufficient. since you can't know
	what the change is
     GW: good point
     SG: I'll think about what we can do. if xinetd needs to do something when it
	starts up. It may be easiest thing to do, is to have default
	configurations
     GW: sounds like safe way to do it.

SELinux base and MLS policy update
==================================

LSPP ks / config script
=======================


PAM and VFS polyinstantiation
==============================

ssh level selection / multiple instances
========================================


IPsec localhost, IPv6, 1st packet drop
======================================
     GW: we were talking about current installation. we'll talk about networking.
	joy can you give us status please with respect to ipv6
     JL: everything should be working ok with the patch I sent. with patch, now I
	can do regular ipsec with lspp kernel. so it seems it cleared a problem.
	with lspp.62 and the patch I am able t do regular ipsec. I am having
	problems with config file for racoon. once I'm done I'll run more stress
	tests and verify all is good. that's about it. if all goes well then
	only issue is the loopback with labeled ipsec. i was looking at racoon
	to see if there is an easy fix. I'll look at that next
     GW: so ipv6 change is hopefully last kernel change
     JL: I made change for labeled packets that affected flow cash and that
	affected regular ipsec. I am only having problems with racoon. As soon
	as I have that right I'll run more
     GW: when do you think you will have results?
     JL: I am working on it now
     EP: it seems I've managed to get every patch for lspp in except for the one
	you just talked abut
     JL: I'll put the patch in bug report
     EP: I already got it and building lspp.63 with it now. it seems we have
	everything in GA and carrying one small patch
     GW: hope that is the case.
     EP: I thought we had alot to carry, but Friday we agreed to take in the lspp
	fixes
     GW: userspace is locking down too, just not sure when.
     IB: it is today
     GW: from what I can gather policy is a bit more flexible. There is an
	interesting property of linux ipsec that came up when Ted and Joe were
	visiting; apparently when you have negotiated connection, the first
	packet gets dropped. most people don't care, but I was just hopping
	everyone is aware of this. since we are negotiating lots of connections,
	customers might see this as non desirable especially BSD ipsec doesn't
	do this
     SG: is it tcp or udp packet?
     JL: does this regardless of packet type
     KW: what happens it returns "temporarily unavailable". it is better if it
	drops the packet rather than returning error
     SG: I think you are saying you do want to fix this
     GW: yes, I think it will be desirable to fix it.
     SG: we need a bugzilla
     GW: I asked joy to open one but wanted to get your read on it
     SG: I don't think it is desirable to return an error. so maybe it is a flag
	that can be set to not let it do that. Either way, first step is to open
	a bugzilla so that people can evaluate it. also a test case on how to
	setup and maybe strace output if needed.
     GW: can you provide that joy
     JL: yes
     SG: if you can do it simply that would be better that the lspp setup we
	currently have
     GW: thanks steve. I wasn't even aware of this property. it will affect
	customers in this environment.

Self tests / aide
=================
     GW: I was hacking on self test policy. As for cron not sure if anyone tried
	it with admin mail. last word from camillo is that it is working
	correctly. looks like we are down to wire. Irena anything you need to
	mention?
     IB: nothing
     KW: Sorry I dropped earlier. I wanted to revisit the xinetd issue. I think
	best in this case is to keep current setup and just document. I don't
	see urgent need to modify xinetd or sshd
     SG: maybe they can set up another alias address and that way they can come
	in through a different xinetd. since xinetd can have 2 ssh running. we
	can properly setup 2 configs one with labels and one without and have an
	alias address
     KW: it might be good idea to encourage admins to not use systemlow for
	regular users. and that might fix things even. ofcourse it might break
	things also but hopefully that is easily fixable
     GW: so systemlow is special and everyone dominates it
     KW: yeah I think that would be safer
     GW: I see that as less risk
     KW: we don't need to require that, but leave it as an option
     GW: I would like to get Linda's opinion on that as well
     SG: hopefully she can reply to the notes
     DW: there is the new policy that fixes the ssh issue. all those should now
	work. and seems policy is almost completed
     GW: one other issue. when using the kickstart script, it relabels and then
	init panics. it used to work, but I'll try with new policy and see if it
	works. we don't want to have to reboot in enforcing=0 on first boot all
	the time
     KW: mls policy manually kicks off relabeling so things get relabeled on next
	boot. but that sometimes doesn't work and kernel panics. it is supposed
	to relabel things before it reboots but doesn't always happen?
     DW: so you have the label file in the kickstart? do you have the -f flag
     KW: doesn't have the -f
     DW: you should probably have that ..
     KW: it has a touch autorelabel since the config file doesn't work
     DW: don't think you need the second touch since it does label twice
     KW: works for some people but not others, so I need to look into it
     DW: only reason to do touch again is if there are processes running that are
	still creating files
     KW: hmm it does a mount, so might be the problem since mount points don't
	match.
     SW: autorelabel does mount -a before it relabels.
     KW: they are all mounted in accessible place for root
     DW: if those paths are ... that can cause a problem
     GW: can't we get it from /proc/mount
     KW: it is wrong at that point ..
     DW: with fixfiles, it get mount table and walks down file system and
	relabels.
     KW: maybe in this case it is better to do it with fixfiles
     DW: we should figure out a way to not have to run autorelabel again
     GW: any other issues. .. Klaus, I think linda was talking to you about few
	issues ..
     KW: yes, some policy changes for xinetd
     DW: yes, I grapped those from you and put in .27 policy
     KW: what's the status of your policy patches for ipsec Joy? and the patches
	I sent you regarding the cipso rules?
     JL: cipso also had some policy changes ... I can ping chris, but not sure if
	he had chance to look at them.
     DW: that's upstream, but do we have them in rhel policy?
     JL: I was looking at pauls work and would've like to have had time to create
	patch that merged our work. see if we can make it smaller.
     DW: try out the latest policy and get to me right away and we'll get the
	fixes in
     GW: anything else?
     KW: is there going to be another public beta before GA. I think last public
	beta had problems
     DW: I think there will be snapshot7
     SG: I think 7 was snapped last week and should be coming up soon.
     KW: one thing useful is to make those public since alot of people don't
	have access to snapshot
     IB: not sure if it'll be public. it'll be on our partner site and also i
	think it will be on rhn on the beta channel. I can ask product manager
	to let you know
     SG: there is probably not alot we can do. there are many other groups with
	their own thing that are part of this release. getting a public release
	for lspp project only is not very likely.
     GW: I think it's good to get feedback
     KW: I think there were issue with beta 2; people who need access to snapshot
	should talk to right people in RH to get that.
     SG: for people doing development, I think there is a development program
	that they can get software releases through as well. There's not alot we
	can do to make it public.
     GW: we suggested for interested people to join developer or partner program
	with you
     SG: I think everything we have is going into fedora
     EP: alot of kernel work is going to fedora through upstream
     SG: we have the kernel public .. so I think they can use that with a fedora 
core
	6 system. I wanna think we are not hiding anything
     GW: that's not the case at all. only some people were asking how they can
	get betas and we told them they need to talk to RH for that. do you know
	what the overhead to join one of those partner programs is?
     SG: no, but I know who to talk to. so if you have names, email me and I'll
	be glad to help
     GW: thanks Steve. Any other issues? ok, we'll adjourn.

Cron
====


Bugs / remaining tasks
======================


Final cutoff date
==================




More information about the redhat-lspp mailing list