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

[Linda Knippers]

Excellent notes!  Just a question or two for KlausW, or anyone else
who wants to jump in.

I'm reading the discussion about xinetd and changing the default level
for regular users.  What isn't clear from the discussion is what the
actual problem is that we'd be working around.

There seems to be an issue with xinetd and ssh in the unlabeled
networking case.  Sounds like xinetd gets confused with the context?
Is the suggestion to have xinetd default to some level above systemlow,
which would be the same default level for normal users?  Sounds
reasonable that the two would have the same default but I don't
understand why it matters what the specific level is.  Is that
related to the mail from Casey, Joe and others about the default
level for existing MLS operating systems or is there a technical
issue with default level for regular users the way it is?

-- ljk

Loulwa Salem wrote:
> 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
> ==================
> 
> --
> redhat-lspp mailing list
> redhat-lspp at redhat.com
> https://www.redhat.com/mailman/listinfo/redhat-lspp