[redhat-lspp] LSPP Development Telecon 10/16/2006 Minutes

[Loulwa Salem]

Disclaimer: This call was very hard to follow. There was a lot of people and a 
lot of discussion going on. I types as fast as I could and tried to follow it as 
best I can. So feel free to correct me if I captured something wrong.

10/16/2006 lspp Meeting Minutes:
===============================
   Attendees

   Lawrence Wilson (IBM) - LW
   Robin Redden (IBM) - RR
   George Wilson (IBM) - GW
   Joy Latten (IBM) - JL
   Loulwa Salem (IBM) - LS
   Michael Thompson (IBM) - MT
   Thiago Bauermann (IBM) - TB
   Al Viro (Red Hat) - AV
   Irina Boverman (Red Hat) - IB
   Steve Grubb (Red Hat) - SG
   Linda Knippers (HP) - LK
   Lisa Smith (HP) - LMS
   Matt Anderson (HP) - MA
   Paul Moore (HP) - PM
   Klaus Weidner (Atsec) - KW
   Darrel Goeddel (TCS) - DG
   Chad Hanson (TCS) - CH
   Joe Nall - JN
   Bill O'Donnel - BO


Tentative Agenda:

Kernel update
-------------
     GW: I hope everyone is running lspp.52 kernel to make sure it is stable. Al
	anything we need to know about the kernel
     AV: nothing going on with respect to mainline.
     GW: Al was saying that there is nothing going on with kernel. At some point
	klaus was talking about not being able to boot with current beta, but I
	got that working fine on ppc. Anyone having any issues with it?
     SG: no one responded on the list saying they have problems
     GW: no news is good news. I assume people are having good luck in that case.
	Anyone wants to bring up any other issues about the latest beta and
	kernel combination?

Beta / Rawhide
--------------

SELinux base update
-------------------
     GW: Anything about selinux
     MA: There were some netlabel policy changes that I pulled last week, I filed
	a bugzilla but didn't see anything, is that going in rhel.
     SG: I'll check on that
     IB: did you file against fedora
     MA: against beta
     IB: is that 210426?

[ we dropped off for a few minutes ]


MLS policy issues
------------------

Newrole & VFS polyinstantiation
---------------------
     GW: As for restricting newrole to admins, there are different mechanism
	that can be put in for that. For server market, Casey pointed out that
	these can be large machines with people logging in. What is the
	possibility of restricting newrole?
     JN: for (CMW?) that I had most access to, if you do set levels which is
	equivalent to newrole it just worked. We routinely log in to machines
	remotely then change them, there has to be a way to log in to box and
	change.
     GW: we are talking about restricting it only to admins
     JN: we seem to have more root level applications. A lot of applications need
	to be root; we will end up with admins ending up with privileges more
	than what they already have
     GW: which is not desirable
     JN: in CMW model there is a privilege to write the audit.
     SG: your applications need to start as root then drop privileges.
     JN: we just have not gotten to that point of work.
     SG: dbus and name service caching daemon has a patch that shows how to drop
	privileges.
     GW: Newrole is scary for everyone. Mike Thompson has been working on it,
	Mike any updates?
     MT: the work I did I sent out to the list and only stepehen smalley had
	minor comments, mostly my use of a naming scheme. If anyone has
	suggestion on how to proceed from here, that would be appreciated. Has
	anyone looked at the patches, I know they are big, that's because they
	do a lot of cleanup since newrole was not suid originally. Did people
	look at the format? At this point basically the state they are in, I'm
	confident and since smalley didn't have much to say, I hope they are
	looking good. I use it on my system and it works. I'll clean up patches
	and send them out later today.
     GW: would the idea be it is always setuid, or just for evaluation
	configuration?
     MT: one of request that dan and RH gave me is to be able to build single
	binary to use on systems that do not need newrole to be suid. and have
	that binary retain those abilities and function to do auditing and
	namespaces. I don't think we found a good solution for that. I was
	looking to have a single binary to be suid or not. Steve suggested if
	you make it non suid, then you check for capability to audit. if you are
	not root, then you don't bother with auditing and namespace, but if you
	are root, you would do that. that's the state of things. It is capable
	of doing what RH wants, doing namespace and auditing. In no suid
	scenario root is audited, and everyone isn't. if that's not an issue,
	then we can go ahead with that solution. one solution Russel Cooker had
	is to break newrole in two packages so you can install it on systems
	that need it. You wouldn't have this extra root hole lying around. I
	like that solution, but it is not my choice
     GW: if we were to incorporate in TOE it would be suid
     MT: it doesn't have to be suid if you restrict to admins only, but if you
	want it open to all, then it has to be suid
     GW: we will make it more dangerous for the evaluation
     MT: you will be adding another suid, so if you consider that dangerous then
	yes.
     GW: that code would need to be analyzed very carefully.
     MT: yes, and I have not seen people looking at it and scrutinizing it as it
	needs to be.
     GW: ok, thanks for the update, put it out again and let people look at it
	and see if they have anything to say. still doesn't answer the question
	if we want it in evaluation. Joe you said there are other systems that
	don't pay attention to pty
     JN: yes, but the CMW is not lspp evaluated
     GW: there is the idea that when you newrole the two ends of pty can become
	at different levels and you can potentially downgrade info on that
	channel
     BO: I would have to check
     GW: it does look like an obvious route to downgrade. It would solve that to
	remove ordinary users' access to newrole. I don't get the sense if folks
	want that or not. also what does it mean to do newrole over a ssh
	connection. this is a ptty console scenario rather than a network
	scenario. I guess this deserves more thought. Since I am not hearing
	more voices, we need to have more discussion on the list. We don't have
	good solution for the pty disclosure route right now. We'll try to get
	more discussion on list and mike will post the new versions of newrole.
	The other issue is how much time we have to put changes in user space.
	Acceptance for Mike's patch need to happen quickly


PTY leakage
------------

Audit userspace
---------------
     GW: Steve, anything new for audit
     SG: no, been really busy with other pieces

Print
------
     GW: Matt, any update on print?
     MA: I got two minor feedbacks based on the patch I posted to lspp list the
	other day, one about the level of messages should be switched, the other
	is to change the access decision type of the generic file. I made the
	changes and sent it out again. It looks like printing is working, we
	need some mls changes that make range printing work. Please test it, and
	let me know of any problems so changes get aback to RH in time

CIPSO
------

IPsec
------

Labeled networking stabilization
--------------------------------
     GW: Ok, for networking, what exactly do we have and if that is sufficient, I
	am not clear on that. The work is continuing to do the reconciliation
	patches, and there was talk about having a run at that. That is causing
	me some worries about the stability and the final outcome in terms of
	features. Joy, also Paul had an ipsec question.
     PM: I had a quick question. can I use ESP or AH for labeled IPSEc
     JL: you can use either one
     PM: what would happen if I use both
     JL: I recommend you use ESP with authentication, but you can use both.
     PM: my question is not generic ipsec, it has to do with labeled ipsec. if I
	use both, do both SA get labeled with context
     JL: I don't think it should matter. you'll have policy that specifies ESP
	and AH, I wanna say you will have one SA
     PM: It will create two SAs
     JL: ok, I'll try it and see and send an emailabout it
     PM: I wanted to see how it will resolve the multiple context.
     JL: yeah, I'll try that
     GW: any specific cipso or ipsec issues?
     JL: I do have a labeled ipsec issue. I brought this up on the mailing list,
	but no one responded. I was playing with labeled ipsec, now I don't
	understand how mls context is used, but I noticed that no matter what
	mls sensitivity I had in policy, SAs were always created with generic
	label. I am concerned, because I though that we wanted to use MLS to
	create fine grained sensitivity levels. I wanted to bring that up, I am
	unsure what the design should be. No one is responding on the list and I
	don't think it is creating MLS portion of SA correctly, but it seems to
	be doing the TE part correctly. I think we care most about MLS though
     GW: I agree, what is it doing Joy?
     JL: It seems that it is taking the flow SID MLS level. I can't find were the
	level of flow SID is getting generated, and I can't see where that is
	coming from. I don't know how to fix that because I don't know what the
	design should be. all I know is that SAs are not getting right MLS
	level. where do they get it from?
     DG: I'll email venkat about that. I'll have venkat look at that
     SG: well, one thing, we should log that in bugzilla so we don't forget it.
     GW: if you do that that would be appreciated Joy
     JL: ok, that's the only issue I had.
     GW: we care about that, so glad you brought that up. let's get to bigger
	question now. Is there plan to pick up the ongoing work, I mean secid
	reconciliation patches
     SG: we are waiting to see where this goes. if it gets working soon, next
	week or two, we might pick it up, but if it drags later that'll be bad.
	since GA kernel will not match what we have in 5.1. We need to see if we
	can pick it up. no guarantee that we pick it up, but we have strong
	reason to do that.
     PM: It seems like james morris is not a big fan of overloading secmark, but
	seems that venkat believes in that. if we need to get that in the
	future, we need to get away from overloading the secmark field
     CH: we would like that, but we need to get another field, and we can't
     PM: but I really don't think we will get another field. one thing we need to
	deal with is forwarded traffic, other thing is local host. to deal with
	forward traffic case, we have flow in and flow out. netfiler has the
	forward hook that ties it to, would that work?
     CH: the idea is we have an ipsec label that comes in that needs to be
	checked.
     PM: kind of what I was afraid you'll say. It is being consumed by machine
	and relabeled. the unfortunate part is that I don't see it happening
	with overloading the secmark
     CH: problem is see to if there is anything else we can use. not sure there
	is anything else we can use. we have multiple label sources
     PM: one thing to remember is that's the only field we have in the skbuff.
     CH: bigger problem we don't know when to use something or not. If we can
	make logical deduction, then we can get around some of this as well.
     PM: The problem is that you are passing this up into user space
     CH: it is transient through the machine
     PM: if it is not going to user space, assuming your policy doesn't change
	and you have static routing tables, you can say before hand the flow of
	packet.
     SG: assuming and relying on routing tables. if routing info gets messed up
	you have to make sure that packets are not routed incorrectly
     PM: I assume static routes are considerd trusted DB
     CH: doesn't really matter.
     DG: everything is labeled
     PM: if you are not sending out on ipsec tunnel then the label isn't
	preserved
     SG: anything going on on e4 are top secret and anything coming in on e2 is
	not.
     PM: if we have static routing, and trust admin will do the right thing, so
	they only do good routes
     CH: it is not subverting the security mechanism in place, there is no
	security mechanism.
     GW: and we would have to document that Paul
     PM: this is just normal routing, normal ip
     GW: but we don't normally make claims about firewall
     PM: this is routing, not firewall.. not saying it is the best solution but
	we need solution at this point. I just think we need to come up with a
	solution. I think the secid work is couple of different things; it is
	introducing flow control that was not there before. then there is
	secmark field and the skbuff struct. it also tries to resolve labels
	down into one 32-bit value. That is 3 potential labels that are getting
	resolved to one. issue is that how you resolve external/internal lable.
	That is causing pain. I tend to think the best way is to give up on
	reconciliation aspect and focus on flow control
     JN: I think there only should be one label
     CH: in general if there is something on interface, the problem is you'll
	always get a secmark label. in theory you'll just use most descriptive
	label. that would be label of secmark
     PM: I think it complicates it a bit. cipso is not best example, this is not
	problem with cipso. you do have to parse, but there is cache in cipso
	code to make resolution pretty quick.
     CH: we have same thing with ipsec because we have that pointer, but it is
	not always there
     PM: if we can soleve that, it'll be much better
     DG: I'll be happy to see that as well
     CH: there are limitations due to current framework
     PM: if we do flow control without reconciliation , it'll be a lot easier
     GW: this sounds like we reached a kind of resolution. maybe we'll add in an
	integer.
     PM: another integer will not be added
     GW: sounds like you'll have full reconciliations
     PM: james morris doesn't like that idea
     GW: are we going to make progress on this. neither solutions is possible
     PM: I think it is hard from technial point. I am not confident the work on
	it will be done in the next week or two
     GW: can james budge
     PM: I doubt that. Secmark is out there, it is user visible, changing it will
	break stuff.
     GW: well, but it has not been out very long, so better to break it now than
	later
     PM: I have feeling the kernel guys will say it is better not to break it at
	all.
     GW: sounds like this discussion will go on, and someone needs to compromise.
	Will it happen in a week or two?
     SG: we'll have to see where things go with this.
     GW: ok, thanks for this discussion. it's a bit clearer to me. we'll talk
	more about that, but doesn't seem hopefull we'll have a full solution.
     CH: if you don't have one consistent model, there are lots of edges to test.
	I am afraid later we'll find edges that we missed.
     GW: we're gonna need to simplify for the evaluated configuration at some
	point. if we can't come up with solution for newrole and pty, then we
	have to restrict newrole. if network reconciliation will not go in,
	then maybe we'll have to look at the compatibility flag. we need to have
	a solution eventually. At least we have cipso there, but no future
	looking solution.
     PM: trusted solaris has something called cipso for ipv6, but there are no
	documents out about that. I'll look into it.
     GW: yes and DoD will request moving to ipv6, and we don't have that solution
     PM: we should potentially implement cipso to handle category issues. we have
	the kernel freeze, so I don't know the feasibility of that
     CH: is this your idea of having different DOIs.
     PM: cipso implementation right now uses tag number one. there are tags which
	use range, or list categories. those are some limitations of the ip
	headers.
     CH: can you enumerate them and have each categories on?
     PM: all comes down to what you set in your header. if you go with enumerated
	one, it's a 16-bit field. The way I plan to implement this is to specify
	list of tags for each DOI. you try to fit in number 1 tag, if not try
	the enumerated tag, then range tag, if that doesn't work, then you fail
	it. it might not work in every combinations ofcourse.
     GW: we'll see what happens, but sure it'll be nice to have a complete
	solution. Steve, I hope you are right and it can be resolved in the next
	couple of weeks.

xinetd
-------
     SG: one open bug and didn't get to look at it

Single-user mode
-----------------
     GW: haven't tested it. I'll drop this from the agenda

Self tests
-----------
     GW: I installed aide on my machine.
     SG: we have new package, with fixes and interfaced with audit system and
	works with extended attributes
     GW: should I pull from fedora extras?
     GS: no, right now it is off james antel people page ../jantel/aide
	(aide-0.12-1.src.rpm). it should run along side iptables. I think we got
	it running after iptables
     GW: Ok, I also pulled iptables from your repo. Networking is still the big
	issue and we need to test with the .52 kernel and other kernels when
	they come out. Any other issues? Ok, We'll adjourn the meeting. Thanks
	everyone.

Cron, tmpwatch, mail, etc.
---------------------------

Bugs / remaining tasks
----------------------

Final cutoff date
------------------