04/09/2007 lspp Meeting Minutes:
===============================
Attendees
Lawrence Wilson (IBM) - LW
George Wilson (IBM) - GW
Kris Wilson (IBM) - KEW
Loulwa Salem (IBM) - LS
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
Amy Griffis (HP) - AG
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-3.el5
audit-libs-1.3.1-3.el5
audit-libs-devel-1.3.1-3.el5
audit-libs-python-1.3.1-3.el5
cups-1.2.4-11.8.el5
cups-devel-1.2.4-11.8.el5
cups-libs-1.2.4-11.8.el5
ipsec-tools-0.6.5-6.2.el5
kernel-2.6.18-8.1.1.lspp.72.el5
kernel-devel-2.6.18-8.1.1.lspp.72.el5
kernel-doc-2.6.18-8.1.1.lspp.72.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-askpass-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-50.el5
selinux-policy-devel-2.4.6-50.el5
selinux-policy-mls-2.4.6-50.el5
selinux-policy-strict-2.4.6-50.el5
selinux-policy-targeted-2.4.6-50.el5
vixie-cron-4.1-67.el5
lspp-eal4-config-ibm-0.29-1
rbac-self-test (patches submitted for config RPM)
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
JN: I opened a few bugs today, bug# 235720. also an issue with
/var/log/messages being system low
KW: have you tried if processes can send msgs to higher levels
JN: It either can write down or syslog can't work above systemlow, either
way is broken. I assumed write down worked since sytemlogd is running at
systemLow-high
KW: ... you have to look and see
LK: what's the bug number
JN: bug 235725
GW: we may need to add both to list. General items for discussion? we need
to talk about severity of bugs Joe just opened. Also, I sent klaus
patches for self tests to incorporate them into KS config package. Other
issues people want to bring up before we dive into bug list
KW: I posted version of KS that has that integrated self tests if people
want
to test it
GW: I would appreciate testing and feedback. I know policy does not work at
systemhigh and I am trying to fix that
KW: I think this also was the last piece we needed, also thanks to Linda for
her patches. I think the script is now complete; if people have any
issue let us know as soon as possible.
Bug List: (Sun Apr 8 22:23:46 EDT 2007 - 12 bugs found.)
ID Sev Pri Plt Assignee Status Summary
218386 med nor pow [EMAIL PROTECTED] ASSI LSPP: labeled ipsec does not
work over loopback
JL: I submitted patch to ipsec tools but did not hear back. over weekend I
left stress tests running and noticed today that on 72 kernel with
latest racoon, if you leave it running, after a certain amount of hours
(about 17 in this case) racoon stopped negotiating SA. The complaint was
it could no longer open shared key file, and could no longer do the
is_selinux_enabled call. George and I noticed that on the machine
initiating there was huge amount of file descriptors (fd) open.
I'm investigating that now, at first I thought it was result of my
loopback patch, but then I ran it with just racoon (without my patch)
and I see it in that too. so it's not result of the patch
KW: sounds like something is opened but not closed. use lsof to see
GW: yes we used that, and we saw lots of sockets still opened
JL: I'm trying to debug it, and not sure why I have not seen this before.
When I initially saw this it had been running for 36 hours. I need to go
back and check more
SG: try the GA version, to see if it's a patch we added or something already
there.
JL: I have a bug opened for that, I'll look it up
SG: about those patches, status is we just got the ok to build that one.
overnight I should have a new ipsec-tools package out.
JL: I don't think this is result of loopback patch, so if everyone wants to
try it I'd welcome that
GW: can people maybe run a cron job with lsof to monitor it while they are
running with the loopback patch
JL: it usually happens on racoon that is on the initiator side. The bug is
235680
GW: that one is on the list actually, and you had all the info in it?
JL: yes.
GW: is that the only problem you see with loopback
JL: I don't think it is related to loopback
GW: should that be built then
JL: yes, the sooner we test and use that the better
GW: is the plan going to be to build that one then steve?
SG: yeah, we just got ok to do build on that one. same with 234491.
JL: both of those patches I sent to ipsec tools and I am still waiting on
response.
SG: we got ok on both of those.
GW: Ok thanks.
225443 med nor ppc [EMAIL PROTECTED] MODI LSPP: No
console login on first boot
GW: I was still seeing that and got confirmation from Linda and matt as
well. matt installed the extra audit module and saw more messages
LK: I don't think we tried the latest policy
GW: yeah, I have not seen it.
SG: I think we are still waiting on the build
GW: .50 is the last version in repo
LK: so only .50 is there. we are waiting then to verify this one.
228366 med nor All [EMAIL PROTECTED] ASSI LSPP: audit does not log obj
label for signal recipient
SG: thinking amy updated that one and Eric was supposed to check on it. I'll
check on that
LK: yes amy updated it
231090 med urg ppc [EMAIL PROTECTED] ASSI LSPP: getattr
causes python Segfault
GW: klaus k added a dump on the fifth.
KK: I can use some help with this bug, I can't get a test case running for
i386. and the syscall giving me problem is found on i386, z and ppc.
GW: so this is impacting ppc and s390
SG: I've never seen it, not sure if Jeremy is looking at it. It crashes on
my x86, so it's hard to really tell if it's a bug in test case or kernel
or python bug. On the machine it is supposed to work on it's not
working. I don't know what to think. I feel Jeremy is in the same boat.
GW: you are having problem reproducing it.
SG: Jeremy says that first thing to do is go through test case and fix bugs
in test case.
GW: the problem is that it should run on i386 or x86_64
SG: it ought to be on all
IB: is that applicable to version 2 of the test case?
SG: I have to check
IB: it's attached to the bug
KK: this status is specific to ppc and it was not available to i386. I also
attached the back trace where I am having this segfault.
SG: also you need strace to go with it.
KK: I can try attaching the strace also
SG: have you tried running in GDB
KK: yes the backtrace from GDB is in the comment. And with python debug
installed.
SG: does gdp do anything that looks like null pointer. what is it crashing
on
KK: it looks like it is trying to assert structure member. it is trying to
access exec_exe type and whole thing segfaults. strange thing is that I
can't see any misuse of c function we are using inside the swig
libraries. It should be able to execute if we have mac permission. I can
try working further with it and provide strace. I think strace was
running indefinetely with this test case, and didn't have time to look
at it further. but I'll look into it
GW: what else can we do to make progress on this Steve?
SG: can you have anyone else look at it. Jeremy is looking at FC and extras
merge, so I think he'll be busy
LK: I built v2 on i386 and it runs. so you might try it to make it easier to
trouble shoot.
SG: ok, i'll try
GW: klaus k is looking at it, maybe we can all take a look at it and get
more info. So we need info from our side
LK: test case does not build on x86_64 cause of syscall number
231392 hig med All [EMAIL PROTECTED] NEW LSPP: Misc soft-lockups in x86_64
lspp.67 kernel
LS: this is the lockup I saw last time and I can't reproduce it. Someone
said it was going to be left aside if we can't reproduce it
SG: I thought it might be the soft lockup detection code that has the
problem. one thing to consider is the tests have alot of overhead, so it
may have a delay to get back from CPU. once we remove all debug code, it
should be faster.
GW: so we still have debug code?
SG: yes .. since we are still adding patches
GW: none of us can run with that in
SG: right .. I think we added all the patches we need for now.
EP: there is one that Joe added .. James will look at it, I'll be out rest
of the week.
GW: do we have target for .73 kernel.
EP: I can get it out tomorrow, but definetely there will be at least one
more coming
GW: ok, I am trying to get a read on what to expect.
EP: I'll get you one tomorrow, but once James is done we'll get another one
GW: good. both Linda and I need to have idea on when we'll have it.
231529 hig med All [EMAIL PROTECTED] ASSI [LSPP] bogus audit records with
cups printing
SG: still looking at that, but leaning towards closing it.
GW: ok, exactly what I had from last week
233153 med med x86 [EMAIL PROTECTED] ASSI LSPP: semanage not always
removing entry from /etc/selinu...
LS: joy and I we looking at this, but did not find anything yet.
JL: it's not semanage it seems. it's a library call to libsemanage
DW: you know how this happened
JL: so far we are still trying to figure it out
LS: the test case has a comment that says it has to make direct calls to
libsemanage because you can't directly manipulate nodes from semanage.
so we are still trying to figure out all the functions it's going
through
DW: why are you calling the library. semanage then should handle nodes, you
might want to open a bug about that.
LS: ok .. so we'll open one
234491 med med All [EMAIL PROTECTED] ASSI LSPP: kernel sends additional
ACQUIRES that racoon is not...
GW: we already talked about this. It's getting ready to be built
234923 med med All [EMAIL PROTECTED] ASSI LSPP: update lspp.rules file for
evaluation
SG: have not had chance to look at this yet
235321 med med All [EMAIL PROTECTED] NEW LSPP: audit DAEMON_CONFIG record
truncated
SG: worked on this and right now writing a patch to the daemon
235398 med med All [EMAIL PROTECTED] NEW LSPP: ausearch does not correctly
find out of order records
SG: this has existed since RHEL4 and was scheduled to be fixed in auparse
library. I don't know about switching everything to auparse
LK: question is does it block evaluation when it didn't in the past. maybe
we can get an opinion from klaus
GW: it may be problem for audit selection
KW: I think it is border line. you can argue that the file is human readable
and data is in the file, so can argue that it is not a big deal, but the
expectation is that audit parsing functions will work as you expect them
to. I'll check with evaluator.
SG: later this week I may look at doing that fix.
LK: as a work around, someone can always sort the audit log.
SG: well, it's a nasty workaround. The tool now can take stdin, so you can
do some shell work to get everything together then pipe it into
ausearch. if we do have to fix this one it'll be end of this week, or
early next week to start looking at it. They way to fix it is probably
in ausearch tool, then I'll step up the audit version.
GW: let's see what evaluator thinks.
235468 hig med All [EMAIL PROTECTED] MODI LSPP: ausearch does not
return DAEMON_END record when sea...
SG: patch done and will get packaged
235475 hig med i38 [EMAIL PROTECTED] ASSI LSPP: Panic when running
IPSEC labeled loopback on LSPP k...
GW: assigned to james, we don't have read when that one will be done
JN: only way to do it is to put a bigger setrans.conf. I can reliably panic
the box in two lines of code
GW: so far it's only on 32 bit
JN: I only tried it on 32 bit
GW: has anyone tried this on 64 bit?
LK: I care about 32 bit
SG: is 32 bit going to be evaluated
LK: that's the plan
JN: I can try it on 64 bit.
GW: and just because we have not seen it on 64 bit doesn't mean it's not a
problem
JN: problm maybe that vendor supplied translation files are not very
stressful. when we started exploring limits we ran into these issues
SG: last eval there was lots of testing with file names at maximum size, I
don't know if we are stressing the context size. I know Linda found an
issue and based on that, I found similar issues in few other places. I'm
fixing that but we should have tests to stress the context. I think
selinux is smart and it tries to consolidate them.
JN: I did all even and all odd to avoid it consolidating.
SG: ok, good
GW: it will help us all to try to invoke this. I'll give this a shot on ppc
to see what happens
SG: I'm wondering if pam has everything the way it should be so it's not
truncating anything. if you log in with long context, are we gonna get
all that info in PAM. it's alot of gray area
GW: yeah, there are lots of possibilities for breaking. we have tests that
use large number of categories, but not running on 32 bit.
235675 med med All [EMAIL PROTECTED] ASSI LSPP: INFO: possible
recursive locking detected
GW: Linda found this one
LK: I don't know anything about it more that what I put in there, it seems
it had to do with pre-link.
GW: could this have been provoked by debug stuff in kernel
LK: I assumed the debug coded causes it to be detected, but not happen
EP: I doubt it'll cause it, but debug shows you the message. I'll try to get
someone to look at it
GW: you say it's possible, so it might not be happening
LK: yes. and everything kept running, so I'm not sure.
235680 med med pow [EMAIL PROTECTED] ASSI LSPP: racoon is unable
to open files after running for 17...
GW: already talked about that one. this is the fd leak in racoon.
IB: who is looking into that
GW: Joy is looking into that actively
SG: it's not a fd leak, but socket leak.. right?
GW: yes ..
235725 med med All [EMAIL PROTECTED] MODI In LSPP configuration
/var/log/messages is SystemLow
SG: seems like messages should be at syshigh. if it opens up anything else,
which it may have info that you don't want people to see. so probably
all files that syslog writes to should be high.
LK: why is it actually working
JN: I didn't look at code alot. the daemon is running low-high and writing
it's files at low. it really just had not been looked at
GW: sounds like a downgrade to me
SG: you can send info to syslog,and get info
LK: can someone identify what in policy is allowing it to happen. I was
looking if type has special privileges or is it a trusted object
JN: I think it's because it's a low-high daemon. if I did this on permissive
system it's one of two bug ..
KW: if you are testing in permissive you can't tell if protection is working
or not.
KK: it won't make difference if it's sytemlow-high, since sysadm for example
has overrides.
SG: what did we do for audit daemon .. if it fails it writes to syslog
SG: I agree, stuff should be high.
DW: it's a trusted object so you can write to it not read from it.
LK: are there any tools like log rotate that will break or are they running
at the right level
DW: logrotate has overrides I believe.
LK: so who wants to look at this
DW: me, I'll take a look at it.
235720 med med i38 [EMAIL PROTECTED] NEW LSPP: setkey -D fails for
large numbers of Security Assoc...
JN: I used the setrans.conf file attached and script that goes with it which
creates 100s of SA, when you get to 195 it stops.
CH: are you using setkey to display that
JN: yes
CH: that does not work.
GW: we talked about this.. you have to use netlink
CH: yeah, so you need to not use pfkey. that's a fundamental pfkey issue
GW: has anyone made changes to ipsec to use netlink, since we talked about
that
CH: we never got around to it since we switched to openswan which already
uses netlink
SG: we heard from alot of networking people that ipsec-tools is not the way
we want to do things next time
CH: Venkat is working on porting things to openswan.
JL: so you have all the code we need in openswan?
CH: not yet
SG: and we don't package openswan with RHEL
CH: right .. it's in Fedora
JN: so is this a duplicate of another bug?
JL: Chad, are you planning on submitting it to openswan.
CH: yes
JL: It'll be a good idea since alot of people prefer openswan. out of
curiosity, does openswan have the loopback issue
CH: I think it does, but I don't know the answer to that. James morris
prefers that I remember
JL: yes, he liked it more, he says it has better SA management
CH: and the openswan mailing list is more active than ipsec.
LK: would that be an option for what we are doing now
JL: does it have an IKE daemon?
CH: I believe that's what Pluto is
GW: yes I'm curious about Linda's question too
LK: is it blocking bug from an evaluating perspective
CH: they are all there, but kernel won't allow you to dump them all out.
temporary hack is to change a kernel line to not have a resource limit.
SG: that particular issue is not going to be decision for me or Eric to
make, so we would need to take it internally
LK: so we'll just live with it? trying to figure this out
CH: it existed with ipsec for a while.
JN: I think it'll be an issue that will happen alot
PM: and I think it'll happen even not only on loopback, but also creating
SAs.. and many other scenarios
JN: if I run simplest data, I end up with few hundreds on the box
PM: and expand that for each SPD .. I guess the point I am making is that
even if not on localhost, trying to talk to remote host will cause you
to create lots of SAs anyway
JN: I agree
GW: RH bug 181617 is about the same issue. it was closed by steve, with
comment "patch applied in April". was that openswan since this is
against rawhide
SG: this was April of last year?
LK: yes, but it was closed last September.
JL: I'll look at mailing list archive to see if there was a patch
CH: there was no patch from our part since this was a design issue
GW: we've known about this for long time. should we have been doing our work
on openswan
CH: it's not in RHEL ..
GW: should we have opened issue tracker(IT) to include openswan before
SG: it's possible, even if you open one now, I would fight for it given the
circumstances
EP: do you have documentation that people can take a look at for openswan
CH: not yet ..
PM: if you are working on it, it would be good to share it since we are just
learning this about it
GW: seems to be a good direction for us to pursue. We knew about this a
long time ago, I wish we lobbied this long time ago
SG: we can lobby still
GW: but it won't be possible for this evaluation. we are trying to have
everything closed at this point. maybe it can be added to 5.1, I don't
know though, adding packages in updates is not looked upon kindly.
SG: looks like in changelog there was something around April 18 where we
applied a patch to ipsec tools. I'll look to see if there was a patch
that got lost somewhere.
GW: that would be great to see if we have fix for this. people are going to
be hitting this.
GW: so we are not done yet and it looks like next week is earliest we will
have anything
SG: bug number is dropping, but we still got more to go.
GW: yes, we are getting close
SG: I'll be publishing the .52 policy in few minutes, and hopefully tomorrow
ipsec-tools will be out
KW: I talked to Stephan on audit bug we talked about, and he agrees that it
is not a show stopper as long as it is logging. no immediate need to fix
it
GW: do we have to document it.
KW: wouldn't hurt to do that
GW: any other issues to bring up? Thanks Joe for helping test and bring up
those last two issues
JN: you're welcome
DW: I'll put out a package with syslog logs at systemhigh for people to try.
I'll put it out tomorrow
SG: if you want to open feature request about openswan, go ahead and open it
in case we need it. assign it to me and I'll work on the politics on
this side
GW: should that be an issue tracker
SG: probably go through the proper channel to request feature. Actually I'll
open a bugzilla, then you can attach issue tracker to it. we can get
that started at least
GW: anything else? ok, we'll adjourn and we'll continue testing. bye. Thanks
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
