[redhat-lspp] LSPP Development Telecon 02/19/2007 Minutes
Loulwa Salem
loulwas at us.ibm.com
Tue Feb 20 22:49:55 UTC 2007
02/19/2007 lspp Meeting Minutes:
===============================
Attendees
Loulwa Salem (IBM) - LS
Debora Velarde (IBM) - DV
Michael Thompson (IBM) - MT
Joy Latten (IBM) - JL
Kylene J Hall (IBM) - KH
Irina Boverman (Red Hat) - IB
Steve Grubb (Red Hat) - SG
Dan Walsh (Red Hat) - DW
Eric Paris (Red Hat) - EP
Lisa Smith (HP) - LMS
Klaus Weidner (Atsec) - KW
Chad Hanson (TCS) - CH
Ted Toth - TT
Agenda:
Agenda and Meeting Formats
Bug Discussion
Around the Room
RHEL 5+ Packages:
kernel-2.6.18-6.el5.lspp.64
kernel-devel-2.6.18-6.el5.lspp.64
kernel-doc-2.6.18-6.el5.lspp.64
mcstrans-0.2.1-1.el5
selinux-policy-2.4.6-32.el5
selinux-policy-devel-2.4.6-32.el5
selinux-policy-mls-2.4.6-32.el5
selinux-policy-strict-2.4.6-32.el5
selinux-policy-targeted-2.4.6-32.el5
audit
vixie-cron
LS: George is out on a family emergency, I don't know when he'll be back.
I'll moderate the meeting today. Thanks Irena for providing me with an
updated list of bugs for the agenda. George sent me an update on the
list of packages to include vixie-cron and audit
KW: cron from Dan, and audit from Steve is that it? What versions should we
have?
LS: He didn't have version numbers .. just the package name.
SG: we are one day away from FC 7, so that took some time from me, I've been
looking at bugs, to make a long story short, I have not built an audit
lspp package yet, should get to it this week.
KW: are there patches that we need to try separately, is this 1.3 or a
version update?
SG: I have 2 patches to back port and third item that gets rid of using id
program from init script and uses shell script variable instead, useful
if user is using a network device.
KW: wanted to be clear if we are doing installation, what should we be
using. should we keep the rhel5 rc version
SG: yes, and the audit package I'll get out this week is one number higher,
the version should be -2. there is no intention of moving to 1.4 or 1.5.
KW: Are there any visible changes, any known failures we should be expecting
with current versions. just so we know if things don't work, what the
new version would do.
SG: There are three patches ..
KW: are these bugs in relation with list we'll go over, I can wait
SG: well basically, ausearch -se didn't work at all, so I have a simple fix
for that. The -se option should search on either object or subject
context, it was doing "and" instead of "or" so it wasn't working. There
is a bug fix I mentioned when replying to Stephen Smalley, it's the perm
fix in libaudit, not being able to audit by context and certain
permissions. then there is the euid update, to take the call to id
program out of the init script for network devices. Apparently there is
quite few people that use network devices.
KW: I see the bug 226780. Are there any more for the issues you mentioned
LS: let's go through the bugs then and see what those cover, then discuss
what's left after that.
SG: there are bugzillas that are associated with the others but not lspp
related. do you want them
KW: don't need them if they don't affect us.
Alias Sev Pri Plt Assignee Status Resolution Summary
218386 nor nor pow ASSI LSPP: labeled ipsec does not work over loopback
JL: made some progress on that one, the errors I was seeing in log file are
now fixed. This morning, I ran a stress test and didn't see errors in log
file. Tonight before I leave, I'll start several stress tests (using .65
kernel), one over loopback, eth0, and eth1. If all looks fine, I'll send
the patch to ipsec-tools and leave it to them for review.
LS: so is it fixed now?
JL: I won't consider it fixed until I see what they say. My base is the
patch that Paul sent out.
223532 nor nor All ASSI [LSPP] crontab manpages reference older environment
variable
KW: last comment in bug is from Irena saying it is in the modified state.
SG: it turns out no one really applied the patch and built the package. I'll
try to get that moving this week.
LS: should we expect another cron package then Steve
SG: yes, the bug should be fixed before we get it in modified state.
223840 hig nor All NEW [LSPP] getfacl fails to correctly display all
information...
SG: The maintainer created a patch over the weekend, klaus reviewed and it
looks good. The next step is to build package. The "acl" package is
going to need to be carried.
KW: can we make the oldest bug about this issue public (bug # 128265)
IB: I'll try to do that, but couldn't change it myself
SG: that one was related to rhel4. it is in errata system, so we don't have
control over it.
KW: if it causes problems then ignore it
SG: only thing we can do is clone it
223864 nor nor All NEW LSPP: Exceptions to expected audit behavior should be
doc...
LS: What did we agree to do with this one?
SG: we talked about putting proper documentation for it in user's guide.
LS: who's taking action on that?
KW: there are multiple guides, I'll take action on that for the guide I am
maintaining. Others need to do the same.
223918 nor nor All ASSI LSPP: audit logs bogus obj label in some PATH records
EP: fix for that should be in lspp.65
KW: I see comment on RH bug stating that.
LS: great .. we'll test it.
LMS: I had a related question, there were couple of bugs that Amy worked on,
should we be posting bugzillas for those
EP: at the moment I have all the bugzillas I want
223919 nor nor All ASSI LSPP: audit does not log obj label when opening an
existi...
EP: all the audit bugs are related, Al is looking at the one about tracing
signals. The other one # 228366, I have a patch for it and we need more
review on the patch. For # 228384, there is no patch and not sure who's
working on it
IB: I thought we'll get Al to look at it
SG: I didn't run across Al the last couple of days.
KW: do we have plan B is case we don't reach Al
SG: Amy will be back next week, and we can talk to her then. Either way, I
think Al will get involved in writing it or help review it. I'll see if I
can get hold of him.
EP: everything else that says audit in subject, there is patch for and
should be in .65 kernel.
LS: Ok, Let me go through the list for those bugs and make sure I got them
straight.
224080 nor nor All NEW LSPP: audit does not log obj label for
mq_timedreceive/mq...
EP: closed as duplicate of 223919
225328 nor nor All ASSI LSPP: ipsec drops first packet when using IKE daemon
JL: I loaded the .65 kernel and it actually worked, I'm happy with it. I
tried labeled ipsec, and looked like it was working fine. I am currently
running sniff test and it seems to be going well. I'll run it over night
and if it works fine, tomorrow I'll kick off a regular ipsec test to
make sure it didn't regress. Only concern, it needs to work in lspp and
upstream kernel, and when I patched upstream kernel (2.6.20) it
panicked. I opened the bug about audit log task context problem. I could
try the latest git kernel, but I'm thinking I need that audit patch
before I make additional progress. On our lspp kernel I don't see that
audit problem.
LS: should we keep this bug open until you try both kernels then
JL: yes, this bug still needs lots of testing.
226780 nor nor All ASSI LSPP: audit of writes to files of bin_t produces no
records
KW: Steve talked about it earlier.
228107 nor nor All NEW [LSPP] Labels for labeled printing don't linewrap
LS: Matt was working on it, do we have an update?
LMS: I believe he is still working on that, but I have no status.
228366 nor nor All ASSI LSPP: audit does not log obj label for signal recipient
LS: Already have patch for and in .65 kernel (per Eric's above comments)
228384 nor nor All ASSI LSPP: audit does not log obj label for traced process
LS: There is no patch for this one. Will get Al to take a look at it or
follow up with Amy when she gets back. (per Eric's above comments)
228398 med nor s39 ASSI LSPP: Not able to ssh into the machine with multiple
cate...
KW: There were two issues, it didn't work on labeled translation which is
fixed now. Second is if you have large list of categories it didn't
work. That one is less critical since it failed securely and doesn't
need to be fixed for certification.
SG: I think we want to fix that one, it's an easy fix. It can check length
.. there is a way of reading polyinstantiated directories with large
number of categories. I'll put these comments in bugzilla, and I'll ask
Tomas if he can look at it. he has been traveling, and doubt he did
anything, unless he worked on it earlier today.
KW: I think currently it's based on using translated context for file name,
just wanted to make sure everyone knew that and everyone is Ok with it.
This has side effects if mcstrans breaks or if you use mappings
DW: It should be working on raw context, so if it's on translated, I think
that's wrong.
KW: are you saying it's intended to, or what you expect it to be using is
raw one
DW: I would expect it to work with raw context
KW: so we still need an action to verify what it's actually doing
LS: who owns this bug
SG: Tomas Mraz
228422 med nor All ASSI LSPP: cleanup xfrm_audit_log interface
SG: last I saw is an exchange between Stephen and Al about kernel code.
Smalley said we should use a different API. It did look like Al is
working on it. need to follow up with him to see if he has a patch.
JL: I think that's the one David Miller posted a patch for. I think I opened
that one specifically because he didn't like the way I wrote it. so he
wanted to clean it up. I think that one is in 65 kernel.
SG: not sure which bug Al is chasing then
JL: Al is working on the one where we transform audit log calls
(audit_log_cntxt). that's what caused the kernel panic in the upstream
kernel. One Al is working on is # 228409.
228557 med nor All ASSI LSPP: In labeled ipsec, permissions are checked after
del...
EP: I got patch finished today, so you'll see something in the morning for
that
JL: Venkat also volunteered to look at it which was great
EP: I'll be taking care of that one, but I have nothing to report yet.
228927 med nor s39 NEW LSPP: odd audit argument on some 32 bit syscalls
KW: we discussed this as well, it is a documentation update
KH: most of the information is in issue tracker, so it's been explained. It
needs to be documented
LS: Ok, so this needs to be in the guide as well
LS: We are done with our bug list, are there any more issues?
IB: bug # 229094, last comment says the fix in in .65
KW: I think the patch is meant for .65 but not in it yet.
IB: Eric, is it in the .65 kernel?
EP: yes it is in .65 kernel
KW: there are 2 issue. One that polyinstantiation should use raw category
and labels instead of translated, if we want to change it, we need a
bug. Related to this, with the latest mcstransd I don't get any labels
translated. I heard unofficially others are seeing this. I don't think
there is a bug report for this.
DW: there is bug, but you need to grab the latest package from my people
page
SG: maybe need a bug to track it.
DW: what version of mctrans are you running
KW: 0.22.1.el5, which I think is the latest
DW: I believe the fixed one is 0.2.3-1
KW: I see it now, Ok, so I forgot to pick up the latest one. Do we need a
bug to make sure it ends up in rhel 5, or are you tracking this
internally
DW: I'm tracking it internally.
JL: I just opened a bug # 229278, I was running labeled ipsec ssh-mls, if I
am a regular user with s2-s5, when I issue ssh -p 222 to user (s3-s9),
my incoming connection is s2-s5, I am able to log in to that user and I
get to be s3-s5. I showed it to klaus and since my incoming level was
s2, I shouldn't have be able to log in.
KW: it seems to be silently upgrading the level. With labeled networking,
your session is always at effective level and not at the higher level
DW: so you think user should be denied.
KW: yes, we can try with cipso as well.
LS: I'll try with cipso
KW: I think it'll work with cipso, ipsec is trying to be helpful and trying
to upgrade
DW: could be that either libselinux or ssh doing something wrong.
LS: any other issues any one would like to bring up?
SG: one thing to point out, over the next 2 days, I'll be a bit distracted
getting changes done for fC7, Wednesday will probably be back working on
lspp items. I am not sure if Tomas can jump on the ssh issue, it depends
on what he has to do for fC7 as well. other than that we should be back
on lspp on Wed.
LS: ok, Anything else? .. alright thanks everyone, We'll adjourn.
More information about the redhat-lspp
mailing list