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&[EMAIL PROTECTED]&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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
