03/12/2007 lspp Meeting Minutes:
===============================
Attendees
Lawrence Wilson (IBM) - LW
George Wilson (IBM) - GW
Kris Wilson (IBM) - KEW
Loulwa Salem (IBM) - LS
Debora Velarde (IBM) - DV
Joy Latten (IBM) - JL
Kylene J Hall (IBM) - KH
Irina Boverman (Red Hat) - IB
Steve Grubb (Red Hat) - SG
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
Agenda:
Bug Discussion
Around the Room
RHEL 5+ Packages:
acl-2.2.39-2.el5
audit-1.3.1-2.el5
audit-libs-1.3.1-2.el5
audit-libs-devel-1.3.1-2.el5
audit-libs-python-1.3.1-2.el5
kernel-2.6.18-8.el5.lspp.67
kernel-devel-2.6.18-8.el5.lspp.67
kernel-doc-2.6.18-8.el5.lspp.67
libacl-2.2.39-2.el5
libacl-devel-2.2.39-2.el5
mcstrans-0.2.3-1.el5
openssh-4.3p2-18.el5
openssh-askpass-4.3p2-18.el5
openssh-clients-4.3p2-18.el5
openssh-server-4.3p2-18.el5
pam-0.99.6.2-3.17.el5
pam-devel-0.99.6.2-3.17.el5
selinux-policy-2.4.6-42.el5
selinux-policy-devel-2.4.6-42.el5
selinux-policy-mls-2.4.6-42.el5
selinux-policy-strict-2.4.6-42.el5
selinux-policy-targeted-2.4.6-42.el5
vixie-cron-4.1-66.2.el5
lspp-eal4-config-ibm-0.20-1
rbac-self-test (TBD in config RPM)
cups (New package pending)
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]
GW: while we are waiting, has anyone tried running aide from command line. I
can't get it to work. I am in the process of posting my self tests.
KW: George, I tried running aide -i and I got permission error just now as
well
GW: need to open a bug on that. I'll post my self tests, and it also
includes a manpage now since someone requested that.
PM: I have question about ipsec. is there a magic setkey command to see
selectors info
JL: you mean the security context?
PM: usually setkey -D to show you updates, is there way to get selector info
as well
JL: by selector you mean src, dst, spi ..
PM: yeah, those are traditionally called selectors in ipsec
JL: I am trying to remember if it is the ipsec protocols or upper layer
protocols that shows up in there. When you input your policy, and you
are not specific about the protocol, I believe you won't see anything
PM: in this case, I am being specific, even specifying ports
JL: I think that should show up, I'll take a look and see.
PM: It's not an issue, just something I was wondering about.
GW: we'll be using the query posted in the agenda, it was sent by Irena and
that should contain all bugs of interest.
IB: George, before we start should we set a time line first about when we
want to finish as we talked about this last time
GW: for each bug, we need to have a target date, I was hoping to drive for a
date of the 23rd, but not all bugs may be fixed by then. I think there
will be little disagreement that we need some completion date. There
will be ideally no further code changes so we can go into formal
testing. Any bugs that will come later will cause test re-spins. At this
point everyone realizes that we need to shut down development. I
proposed that date, and people can suggest others. Does that sound
reasonable?
LK: sounds good to me.
GW: what date would be good for you Linda
LK: happy with the date you proposed
IB: now that we have a date, let's go through the bugs and see where we end
up and maybe discuss it at the end more.
GW: ofcourse, we don't want to discourage people from opening bugs, and we
can decide per bug if it is required/not required for cert. So continue
to open bugs
SG: we need to file any bugs that need to be fixed. last time of rhel 4 we
had problems on syscalls and we ended up doing documentation fix because
we didn't get it early. that's my only caveat and it's based on my
experience in rhel4. If real bugs come along, we need to document it
GW: in particular if it affects our ability to have this in the field.
absolutely write up everything
KW: everybody is aware that what we have kinda works and is good to pass
certification, but not necessarily in practical use. would RH be open to
do aggressive changes that might break compatibility for people. If it
turns out that some design decisions were un-practical?
SG: We'll have to look at them individually, but in general we try to
preserve compatibility at all times. I do plan on making lots of changes
in audit, but keeping backwards compatibility
KW: kind of thing I am thinking about is polyinstantiation and maybe keep it
like it is now, but have different mechanism in the future if people
choose to use it.
SG: I think we would be open for something like that
KW: document somewhere that it might change ... since it didn't get real
world testing, it can be potential road block for future improvements if
we decide to stick with initial designs
GW: there needs to be migration paths also. We found a product in Software
group that wrote some selinux policy but there was no way to migrate it
SG: I think Dan volunteered to help if need be with migration. They really
didn't think about good migration path for policy in the past
GW: I think it gotten better, but something to keep an eye on
KW: we don't expect binary policy modules people may have to work in future
points anyway. source is possible though.
Bug List:
218386 nor nor pow [EMAIL PROTECTED] ASSI LSPP: labeled ipsec does not work
over loopback
JL: I haven't had good luck with this one. using the latest .67 kernel and
the one before that had this patch fix in it, ever since I started
running patch through racoon, I see stuff that I didn't see before. I
thought we will be wasting time and I figured we need to test with more
updated kernels
223532 nor nor All [EMAIL PROTECTED] ASSI [LSPP] crontab manpages
reference older environment variable
SG: that one is built and in yum repo
GW: needs verification
EP: who will do that verification?
GW: who opened the bug?
EP: Matt
MA: I'll do that
223840 hig nor All [EMAIL PROTECTED] NEW [LSPP] getfacl fails to
correctly display all information...
GW: that's the ancient one .. right?
SG: I think there was man page update that needed to occur. looks like Tomas
and klaus exchanged some info on that
KW: there was still updates to be made that Tomas was working on.
SG: I don't see a new package for acl.
GW: we are waiting on new package then
SG: I guess, I'll have to look at bugzilla to see how that's going.
SG: so it looks like klaus asked a question last... so the discussion is not
yet done on that one.
225328 nor nor All [EMAIL PROTECTED] ASSI LSPP: ipsec drops first packet
when using IKE daemon
JL: after testing, I am not happy with this changes so far. I sent patch to
david miller. I've been seeing stuff like double and triple SA being
created. It wasn't correct. when I investigated I saw two things going
on. When I get double SA, the initiating guy was sending two acquires.
When I saw triple SA, the initiating guy sent two acquires and responder
guy sends one acquire. I sent patch to fix the initiating guy sending
two acquires
EP: I think we have half the patch in 2.6.18. the patch you sent to david
miller? I am wondering if that's the one I commented at
JL: yes
EP: ok then, half of it that is applicable to 2.6.18 is in the .68 kernel
JL: My patch eliminated one of the acquires. The other one, where responder
sends one, I have no idea. it needs further debugging. I'll continue to
investigate and see when I fix that and run stress test if things get
better. I saw errors that I didn't see before so I don't feel it's the
racoon patch, I feel it is kernel.
GW: what is the target date
JL: need more work.
GW: this is pending on 218386
JL: My question is "is it very important that we have ipsec not drop the
first packet"?
GW: I say it is important
KW: It is not a requirement for certification, but it's a major usability
issue.
JL: I was wondering since it needs more work and it may have lots of holes
that we need to check before it gets to the level we want it to be at.
GW: is there anyone in community that we might contact to get help. maybe
Venkat
JL: I've been copying him on the mails, but I'll ask him individually
GW: And I'll talk to chad in the symposium
EP: if you can come up with everything that you know, put it in bugzilla or
send it to me, I might know someone in RH that will be able to help with
it.
GW: ok, great .. thanks Eric
228107 nor nor All [EMAIL PROTECTED] ASSI [LSPP] Labels for labeled
printing don't linewrap
MA: this is the one that I was discussing with Linda earlier, it works fine
in portrait mode but not landscape mode. I think it's fixed, just need
to try few things.
GW: when will we have new cups package
MA: the next one is awaiting verification and there should be a cups package
for that.
LK: there is no cups package in lspp repo, so where is Tim putting these?
GW: now that you mentioned it, I didn't see that either
LK: might still make sense to wait for Matt's patches, but there are patches
already available
SG: anybody ever given Tim feedback if it works.
LK: I tried to verify it but wasn't sure how to set it up. he sent me reply
and hopefully I'll test in a day or so
SG: I think he is waiting for feedback to push package
LK: klaus kiwi can test as well, he opened the bug
SG: when we get feedback, I think tim would be more inclined to run it
through system and I can push it through repo.
228366 nor nor All [EMAIL PROTECTED] ASSI LSPP: audit does not log obj
label for signal recipient
SG: this is crashing., we took it out of kernel
EP: was hoping for feedback from Amy as well.
AG: I thought steve you were gonna talk to Al and was waiting. should I keep
waiting or come up with alternate solution
SG: we asked Al to get involved in this bug, so he said he will. I would
expect to hear from him shortly.
LK: is all info related to this bug actually in bugzilla?
EP: I think the 2 problems I know about are in bugzilla.
SG: the other day, I ran with .67 kernel and it finally died on me. It went
through signal code, but oops was not captured. I would have to have a
debugger setup, and at this machine I didn't have a serial port.
EP: maybe use kdump.
SG: it only takes an hour or so of running that kernel and it does all kind
of weird things, if you take signal patch out it works just fine.
GW: do we want to put target date on it
SG: I don't know, I guess we are dependent on Al getting involved
228384 nor nor All [EMAIL PROTECTED] ASSI LSPP: audit does not log obj
label for traced process
SG: I think Al submitted patch this morning
EP: there is a patch in .68 if Amy wants to check it
SG: I am trying to get the user space to understand that type as well
LS: is that going to be a new type Steve?
SG: yes OBJ_TYPE
228409 med nor All [EMAIL PROTECTED] ASSI LSPP: regular ipsec in upstream
kernel crashes
GW: there is patch posted for that one
229527 med nor All [EMAIL PROTECTED] ASSI LSPP: flow cache entries remain
valid even after selinux ...
JL: Venkat and Eric sent me email about how to verify this one
GW: so just needs verification
229673 urg nor All [EMAIL PROTECTED] ASSI [LSPP] cups is overriding mls
when querying jobs with lpq...
229720 med nor All [EMAIL PROTECTED] ASSI LSPP: pfkey_spdget does not
audit xrfm policy changes
GW: it needs verification
229732 med nor All [EMAIL PROTECTED] ASSI LSPP: pfkey_delete and
xfrm_del_sa audit hook is misplaced.
JL: this one needs verification too
230255 med nor All [EMAIL PROTECTED] ASSI LSPP: cipso mapping settings
prevents login into system
EP: Patch is in .68, hopefully Paul can verify that.
PM: I'll give it a shot but might not get to it until next week.
230613 urg nor All [EMAIL PROTECTED] ASSI [LSPP] cups is allowing users to
delete other user's job
230620 med nor All [EMAIL PROTECTED] NEW LSPP:
xfrm_add_sa_expire bug
JL: needs to be verified
EP: I just saw it today, so it's not built in anything. I'll build a .69
this week and put it out there to be verified.
230663 med nor s39 [EMAIL PROTECTED] ASSI LSPP: random problems with the
python rpm
KH: I just added more info to the bug. There is more stuff in Issue tracker
as well that Archana asked me for
EP: that's the guy on vacation Steve was talking about.
231090 med med ppc [EMAIL PROTECTED] ASSI LSPP: getattr
causes python Segfault
SG: check rpm -V of that package. sounds like something is breaking the
files
KW: rpm -V of which file
SG: the python package. I wonder if something is corrupting the files since
we didn't see this before.
KH: this problem has been around for a while. I just got around to opening a
bug and diagnosing it
SG: check the package and have it verified
KW: can you turn on corefile and capture the core dump
KH: there should be no output from rpm -V right?
SG: I think so, might be a time stamp.
KH: I did rpm -V, and it didn't return anything
SG: what about the attr package. sounds like there is a corruption of some
files.
KW: the two bugs are on 2 different platforms
SG: so the libattr is the library python uses
KH: my only concern is that I was not getting any updates on bug since last
week.
SG: in the one Jeremy was asking a question.
KH: I've been trying to respond to questions that are asked
KW: in segfault, it would help in doing backtrace to see the source code of
what was last running
GW: definitely when getattr segfaults, a core file would be great
SG: I know why there has been no activity on the bug, the guy these are
assigned to is on vacation, will be back next week
231178 urg med s39 [EMAIL PROTECTED] NEW LSPP: setfattr
Segfaults on s390x
GW: we already talked about it
231371 med med pow [EMAIL PROTECTED] ASSI LSPP: audit=0 appears not to
disable syscall auditing
GW: steve dropped patch for that. I have faith that steve fixed it but I
didn't try it yet.
EP: patch is in .68 kernel.
GW: great.
231522 urg med ppc [EMAIL PROTECTED] ASSI [LSPP] cupsd
crash
MA: I think tim and klaus were working on it.
GW: I see a new ppc64 package, but don't see testing results. I need to
query klaus
SG: I can push the new package to repo in few minutes
EP: I think he was looking at debuginfo package
SG: he made it public and was waiting on info.
GW: I'll append to bug now and ask klaus to run with that package and post
results
231529 hig med All [EMAIL PROTECTED] ASSI [LSPP] bogus audit records with
cups printing
SG: that one sorta mutated. I think there was patch created for logging in.
wait a second ...
LK: I think that's a different one
SG: I think that's the one we still need to discuss
MA: what this comes down to is there are things nice to know and put in
audit, but there is no secure way of doing that
SG: there is but not bullet proof way
MA: that's what I meant by secure
SG: tim was mentioning that cups is a network device and you can cat what
you want in it.
MA: last comment by tim is that would work over unix domain sockets to.
SG: it is possible to put the file name that audit record is based on.
MA: it is really not, you are getting back to assuming client is honest with
you and you can't make that assumption
KW: sounds like a design fault if server trusts what the client sends it
LK: I don't think it trusts it, and that's why server doesn't know the name
of file
SG: I am also wondering about type.
PM: we have to check the label of the data
SG: is it the label of the user. I really think we still got issues in this
one that we need to look into, probably no action on this bug until
after symposium
MA: I want to get feedback on this, when it was posted to mailing list, we
got feedback asking for title of job, so tracking can be done. and
stephen smalley wanted level and range. it was pointed to me, for some
users it won't always be $1_lpr_t. it may seem for the way we are using
it is not ideal. but based on feedback, it seems it is doing what they
want.
GW: need to meet lspp
LK: we think it does
SG: there are others like NISPOM that we need to meet as well.
LK: but that's what you want for lspp
SG: but you are not getting user's label
LK: we are getting user level and in lspp we don't care about type
MA: and you can get the type if you make policy changes
LK: steve, if you are interested in meeting other standards, we can talk
about it. it would probably require some changes to maybe the protocol
and the cups code.
MA: maybe it can't even be done with this
IB: should we keep this open and say it is needed for others
GW: it appears to meet the lspp requirements. I would vote to remove it from
this list, but continue to work on it for other requirements.
IB: I'll talk to steve and we can decide on it
KW: one thing not acceptable, is requiring a password for each print job,
since that will break test cases.
LK: that's a different bug as well
KW: oh, didn't realize that
SG: I thought there is another way for that also
MA: yes, there is a different authentication way
SG: goes back to what klaus said, system will meet requirements but maybe
not as good as it can be from user experience.
SG: doesn't lspp have requirements for identifying resources used in audit?
KW: specific requirement is if you do security relevant operation on object.
and we have that covered. on unix style system doing that reliably is
hard
MA: that's why you audit the data
KW: I think audit process works for that
LK: yeah, that's what we decided long time ago
GW: we need to discuss more on this
231656 med med All [EMAIL PROTECTED] NEW NetLabel and IPsec management
tools fail to start at boot
231695 med med ppc [EMAIL PROTECTED] ASSI LSPP: user unable to ssh to
system with user/role/level c...
LS: basically we can't log in as sysadm_r with a level. This is causing our
tests to break. It used to work before, but we are seeing it on all
updated systems now. I was getting some context error messages in log
file. they are all posted in bugzilla.
GW: Dan says you need to update the types and contexts files
LS: why doesn't it work now. it used to before without having to change
those files?
KH: and this is a sysadm_r too, so it's not a custom role
LS: yeah, that too ..
LK: maybe update the bug, dan might have misunderstood
LS: I'll do that
231690 hig med x86 [EMAIL PROTECTED] ASSI LSPP: system hangs under
audit stress testing
EP: I believe that is a duplicate of 228409 and we are waiting on stress
tests with .68
SG: that was a memory leak, and we think it's the same function. what's
happening in the other one, turn out that Al's patch he sent this
morning fixes three bugzillas. not a real duplicate, but same patch
fixes all of them
GW: ok, great
GW: looks like we have some indefinite completion dates for some of these,
and may need thorough discussions before fix can be attempted
PM: Eric, I just verified 230255 and it looks fine.
EP: ok, great, I'll take it off the list
GW: sounds like it'll be hard to achieve the date we talked about, but I
think we can drive towards that and do our best since we all agree.
That's it and we can discuss more at the symposium, particularly what we
want to do in the future, what we want to work better, and improvements.
KW: I just posted new version for kickstart script. the changes are little,
mainly minor cleanups. please send me feedback, this should be getting
close to final.
GW: I also posted latest iteration of self test with man page and policy. I
also need to open a bug for aide, I can't execute it from command line.
KW: this is related issue, so far there is no RH package for RBACPP. easiest
way is to have it installed through kickstart. would that be ok with
everyone, or do you prefer it in separate package.
LK: sounds good to me
KW: it would be package, and policy and docs
LK: be good to get the policy changes in
GW: I'll work with klaus on getting it in there
SG: sounds like a good way to go
GW: and my python scripts are still to be improved, so I would appreciate
feedback on my scripts. Ok everyone if there is nothing else we'll
adjourn. Thank you.
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
