[redhat-lspp] LSPP Development Telecon 04/16/2007 Minutes

[Loulwa Salem]

04/16/2007 lspp Meeting Minutes:
===============================
   Attendees

   George Wilson (IBM) - GW
   Kris Wilson (IBM) - KEW
   Michael Thompson (IBM) - MT
   Loulwa Salem (IBM) - LS
   Debora Velarde (IBM) - DV
   Joy Latten (IBM) - JL
   Klaus Kiwi (IBM) - KK
   Irina Boverman (Red Hat) - IB
   Steve Grubb (Red Hat) - SG
   Dan Walsh (Red Hat) - DW
   Eric Paris (Red Hat) - EP
   Lisa Smith (HP) - LMS
   Linda Knippers (HP) - LK
   Matt Anderson (HP) - MA
   Paul Moore (HP) - PM
   Klaus Weidner (Atsec) - KW
   Ken Hake (Atsec) - KH
   Chad Hanson (TCS) - CH
   Joe Nall - JN

Agenda:

		 General Issues
		 Bug Discussion

Repo: http://people.redhat.com/sgrubb/files/lspp/

RHEL 5+ Packages

		 acl-2.2.39-2.1.el5
		 aide-0.12-8.el5
		 audit-1.3.1-4.el5
		 audit-libs-1.3.1-4.el5
		 audit-libs-devel-1.3.1-4.el5
		 audit-libs-python-1.3.1-4.el5
		 cups-1.2.4-11.8.el5
		 cups-libs-1.2.4-11.8.el5
		 ipsec-tools-0.6.5-6.5.el5
		 kernel-2.6.18-8.1.1.lspp.76.el5
		 kernel-devel-2.6.18-8.1.1.lspp.76.el5
		 libacl-2.2.39-2.1.el5
		 libacl-devel-2.2.39-2.1.el5
		 libselinux-1.33.4-4.el5
		 libselinux-devel-1.33.4-4.el5
		 libselinux-python-1.33.4-4.el5
		 mcstrans-0.2.3-1.el5
		 openssh-4.3p2-21.el5
		 openssh-clients-4.3p2-21.el5
		 openssh-server-4.3p2-21.el5
		 pam-0.99.6.2-3.19.el5
		 pam-devel-0.99.6.2-3.19.el5
		 policycoreutils-1.33.12-7.el5
		 policycoreutils-newrole-1.33.12-7.el5
		 selinux-policy-2.4.6-57.el5
		 selinux-policy-devel-2.4.6-57.el5
		 selinux-policy-mls-2.4.6-57.el5
		 selinux-policy-strict-2.4.6-57.el5
		 selinux-policy-targeted-2.4.6-57.el5
		 vixie-cron-4.1-67.el5

		 lspp-eal4-config-ibm-0.38-1

     GW: any general comments before we go into bug list?
     JN: I just wanted to say thanks for the awesome response for the bugs I
	submitted
     GW: well... thank you Joe for taking time to test the product, we sure are
	appreciative to you taking the time and effort to try it out
     SG: Yes, that was really great how you found the leaked descriptors bug
     JN: funny thing about that is that I saw an email from a developer about
	that a while go, but I finally looked into it
     GW: anything else we want to bring up
     JN: we have to work on the setrans.conf so it has labels in them
     GW: good idea. we talked about that on the list when we got the VG change
	issue. Also Linda was talking about the audit messages that are not
	shown with the enable audit. We may want to have an audit mechanism to
	not audit similar to what we have. Linda, not sure if you brought this up
	on list?
     LK: I think we'll have the same issue with the TE don't audit mechanism
     DW: you didn't bring it up on selinux list, did you?
     LK: no
     DW: maybe something we should think about in a greater selinux issue, there
	is a difference between TE and constraints violation and we treat them
	the same now
     GW: any other issues to go through? ok we'll go through the bug list now

Tracker Bug: https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=224041

Query: 
https://bugzilla.redhat.com/bugzilla/buglist.cgi?cmdtype=runnamed&namedcmd=RHEL%205.0%20LSPP&namedowner=syeghiay@redhat.com&order=bugs.bug_id

Bug List:	Sun Apr 15 15:02:06 EDT 2007
ID 	Sev 	Pri 	Plt 	Assignee 		Status 	Summary

231392 	hig 	med 	All 	eparis at redhat.com 	ASSI 	LSPP: Misc soft-lockups in 
x86_64 lspp.67 kernel
     GW: trying to get read if that one still happens.
     SG: there were two different attempts to fix it. internally we've been
	discussing it. It appears there is a lock held for more than 10 seconds.
	that's why we were interested in getting base line timing. I think the
	watchdog kicks in when lock is held for more than 10 seconds. we want to
  	figure out what is going on.
     LS: I'll try the new kernel. Currently my system is running tests, once it's
	done I'll update and see if I still see the lockup. After the meeting
	probably and I'll update the bugzilla.
     KK: I did two runs with the .76 and couldn't reproduce it. my machine is
	different than what Loulwa is using though. I was asking in bug report,
	what is the different between the .75 and .76 kernels? the size dropped
	so much so I was wondering.
     SG: not sure, they are all the same size, I don't have an explanation
	really.
     GW: on ppc we were running with uncompressed kernels, maybe they started
	compressing them.
     EP: build system might have changed.
     GW: we found that the srpms was packaging uncompressed kernels. if it is
	compressed again inside rpm you might not notice much of a difference. I
	don't know
     KK: we still have locking detection enabled though .. right?
     SG: yes
     GW: and that'll stay on
     SG: yes, we have all debug on, if there aren't any more issues, we'll turn
	the debug off and build another kernel. just waiting to see the soft
	lockup issue
     KK: the touch watchdog code is in which one?
     SG: it's in .75, and the NMI watchdog timeout is in the RHEL 5.1 kernel.
     GW: so what do we need to do to help close this
     SG: we need re-test
     EP: can you give us more info about what is going on in the test case
     LS: I'll retest after meeting today. As for what the test case is doing, it
	is basically doing "semodule -R/i/u/r", and I put that in the bugzilla
	also a while ago.
     EP: I can put that watchdog suggestion as Stephen suggested .. we can make
	the messages go away, but I need to track down what is going on
     SG: with 8-way machine, there is more contention for locks ..
     EP: the only contention happens if people are trying to do something with
	linuxfs, but no one should be loading policy at same time
     KK: when I tried to do the case steve suggested .. I used strict policy
	without enforcing, I saw lots of embedded messages, it took about 1
	minute until I saw system was in a loop state, so I rebooted, and I
	could not reproduce it .. just for your information
     GW: what platform
     KK: ppc - JF21 that I posted results for. It took longer than minute, I saw
	alot of invalidating context messages. I was using ssh session, but had
	console open where I was seeing those messages.
     DW: are you in permissive mode
     KK: yes
     DW: you went from strict to MLS
     KK: the other way, I had mls policy, changed mls to strict in config file
	then tried to reload. I was in enforcing mode
     DW: the machine goes out of it's mind. I think all processes would go to
	unlabeled_t and it would crash. going from one policy to another without
	full relabel and reboot is not a good idea.
     KK: I think that's what it was ..
     DW: every time you update policy, it is basically doing a reload of policy.
	If you see lots of invalidating policy messages that would be a problem
     GW: you really want to change config and touch autorelabel and boot. Alright
	I put a note asking Loulwa to retest and comment on the soft lockup
	issue
     LS: will do that after meeting
     GW: and if anyone can test it too, that would be great.

234923 	med 	med 	All 	sgrubb at redhat.com 	ASSI 	LSPP: update lspp.rules file for 
evaluation
     SG: I'll work on that on Wed. one thing I need to get is a list of packages
	we consider to be trusted or part of the security infrastructure. I
	think that has to do with the security target. I'll contact you off the
	list and double check what packages we need to concentrate on. should be
	something that won't take more than couple of hours to work on
     GW: ok, myself and klaus can help you on that

235675 	med 	med 	All 	esandeen at redhat.com 	POST 	LSPP: INFO: possible recursive 
locking detected
     SG: we were waiting for recurrences on that one. On absence of recurrence we
	are leaning to close it
     LK: I am not sure about it, since I only saw it twice and never saw it
	again. the bug fix for upstream is valid though
     EP: yeah.. seemed appropriate for what you are seeing

236060 	hig 	med 	ppc 	dwalsh at redhat.com 	MODI 	LSPP: vgchange -a y does not 
detect vg's
     GW: there is fix, The fix won't work if you are logged in at systemhigh, you
	get the locking issue
     LK: I think it won't work if you are anything higher than systemlow even. I
	saw Dan's note on that about why we don't want to be at systemhigh..
     JN: I think generally you want to do system administration at systemlow,
	what we've seen is people log in at systemhigh and don't change back ..
	which causes problems
     DW: we need to make those files selinux aware. If I am at systemhigh and
	create a file, my file will be systemhigh unless it has selinux
	awareness. This goes for any tool you run at systemhigh.
     GW: so we need to make sure all system administration tools function
	correctly when we log in at systemlow
     LK: I always log in at systemlow
     GW: I think aide needs work . it has to be at systemhigh sometimes
     DW: does it create any files
     GW: no, so that should be ok
     MT: only time we escalate is for audit log
     GW: this needs to be documented again
     DW: by nature, just stay away from systemhigh
     LK: sounds then we are set with this bugzilla
     IB: so I'll take it off the list
     GW: we'll just need to make sure its in the documentation

236316 	urg 	med 	All 	tmraz at redhat.com 	ASSI 	LSPP: Unable to change expired 
password on ssh login
     DW: we are working on fixing this internally. it won't hold up lspp, but it
	needs to be fixed for 5.1
     LK: I think it will hold it
     DW: there is a work around it
     KW: we need to know about it, since we need that information for the
	evaluator to run
     SG: I think we need to fix this Dan. Tomas is working on a fix
     DW: I'm afraid we'll rush a fix that might have a security problem
     SG: It just means we need to review it carefully
     DW: this will involve a helper function
     EP: did we try this on local login
     DW: I tried it and it's broken too. what's happening is that pam is trying
	to manipulate etc_t
     KW: I thought normally pam components are running as whatever program runs
	the library
     DW: right, we want to avoid having those tools manipulate etc_t.
     GW: so that one is in the works and I updated that we need it fixed. Do you
	have target date?
     DW: Tomas is working on it
     SG: we'll try by end of week, but as Dan mentioned we need to make sure it
	doesn't open a hole.
     DW: we need to scrutinize it like we scrutinize the password programs

236479 	hig 	med 	All 	dwalsh at redhat.com 	ASSI 	LSPP: bad aide fc regex
     GW: already fixed and I verified it, so it can come off the list.
     IB: alright, I'll remove it

     GW: any other issues
     KW: wanted to talk about adding limitations to cups .. I think it would be
	good idea
     MA: yes I agree klaus, only reason I didn't send patch was to verify with
	Tim first that I was not limiting the wrong thing. It'll be good to add
	those few lines
     KW: ok, do you want to submit patch, or should I add them?
     MA: it'll only be couple of lines, so maybe easier if you add them
     KW: ok, I will
     LK: one other random thing, George are you working on policy for rbac self
	tests
     GW: yes, I got rid of a problem and still trying to make things work
	correctly.. Ok, any other items? alright thanks everyone, we'll adjourn