[redhat-lspp] LSPP Development Telecon 02/12/2007 Minutes
Loulwa Salem
loulwas at us.ibm.com
Tue Feb 13 00:44:09 UTC 2007
02/12/2007 lspp Meeting Minutes:
===============================
Attendees
George Wilson (IBM) - GW
Lawrence Wilson (IBM) - LW
Kris Wilson (IBM) - KEW
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
Tomas Mraz (Red Hat)
Lisa Smith (HP) - LMS
Linda Knippers (HP) - LK
Matt Anderson (HP) - MA
Klaus Weidner (Atsec) - KW
Chad Hanson (TCS) - CH
Tentative Agenda:
GW: Irena sent a list of bugs. We'll use tracking bug 224041 that Irena
opened for us. If everyone can get that bug opened so we can all be on
the same page. We'll go directly off of Irena's tracker bug. Once on the
bug, if you expand dependency tree you get the nice list we'll go over.
SG: there is one thing I wanted to do, as we go through the list, we can add
a name to who is working on it. All that you have is the RedHat
maintainer, who may not be the person working on it
GW: makes sense .. absolutely. Who wants to do the updating
IB: I can update the bugzilla. just put info in meeting note and publish it
as well
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
Bug List Provided by Irina Boverman Fri Feb 9 13:58:56 EST 2007:
ID Alias Sev Pri Plt Status Resolution Summary
211827 nor nor All ASSI LSPP: Can't mount with additional contexts
GW: this one has been reopened by klaus kiwi in Brazil.
LK: looks like Dan updated it today as being fixed
DW: mcstrans is still a bit broken. The problem is we don't really have good
syntax for it. I sent out an email suggesting what I would like to see
done with it.
LK: does this bugzilla need another update saying it is not fixed then?
DW: we fixed the ssh, the problem now is that the translation is still not
working. translating multiple categories is a bit difficult. I am
trying to figure out the best way to code it up.
SG: Are you saying this bug is mcstrans and not util-Linux related?
DW: correct. There is bug in setrans that was truncating labels
CH: it's entirely a translation problem
DW: it's truncating everything after first comma. the ssh problem and mount
problem are really same thing.
SG: we should close one as a duplicate of other
DW: should really close both and open new bug on translation. these two bugs
are just reporting a symptom of bad translation. The real problem is the
translation mechanism. I think the way I understand it it's difficult
because of all rules we have
SG: are we gonna close these two and open new one then?
DW: mcstrans is just broken
GW: so we need to design new syntax
DW: if you had left hand side translated, then you return left hand side.
The curent code looks for sensitivty then tries to translate entire left
side. if you have a range, it translates right and left sides
separately. we are trying to optimize it to use least ammount of
characters and be easy on people filling up the table. I think this is
better discussed on the list. I will try to write syntax then write code
to match that syntax. I don't want to have to specially code systemHigh.
GW: Ok, so we need to hammer details on list. this will affect selinux as
well as lspp?
DW: On selinux side we ignore sensitivty so it's not a problem .. that's
why it wasn't caught before.
GW: ok, sounds like we need to take this off line
IB: libselinux it's not on the list ...
GW: these 2 bugs will get closed and new one will open and we'll continue
discussion on mailing list.
LS: who's going to take action on this bug?
GW: Dan volunettered to close other two and open a new one
218386 nor nor pow ASSI LSPP: labeled ipsec does not work over loopback
JL: I didnt' have time last week to check this. I'll try this week.
GW: do you mind your name being assigned to it
JL: not really, but I don't know who else will work on it. I know the issue,
I just need to go see if it is someting we can resolve.
GW: 219611 is currently closed. why is it still on the list
IB: I'll remove them, sometime is shows up if discussion is still going
SG: I'd consider those closed.. if there is still discussion it should be
re-opened. Modified means it has been fixed and still waiting QA review.
220482 nor nor All ASSI LSPP: CIPSO-to-unlabeled TCP connections block
LS: Paul had put a comment in the bugzilla and I tried his suggestion (to
try the connection in the other direction). From what I can see which I
also posted in the bug, the communication doesn't happen as long as one
system doens't understand cipso and the other does. What seems to be
happening is that the none cipso system doesn't understand the cipso
option it's receiving and drops the packet sending and ICMP error ack to
the cipso system. I thought that was the expected behavior and Paul
confirmed that. Now I am just waiting for Klaus to say if that is
satisfactory.
KW: I think it's been two separate issues, first there was specific bug for
kernel not allocating enough memory for the header. This is now a
separate issue but I am not sure what the problem is. For evaluation
puprose, it is ok if two (cipso/non-cipso) systems don't talk to each
other
SG: what about ability to export data requirement?
KW: The cipso configured system can reject unlabeled packets which we have.
From evaluation point of view I don't have an opinion on that
GW: if it meets the requirement is this going to be acceptable to everyone?
IB: if it's not a bug it should be changed back to modified.
LK: well, the original problem was fixed ..
GW: so is this ok. it's really a RH call
SG: seems people would want the ability to export to unlabeled medium if
they want to.
KW: this problem is only if you have netlabel on.
LS: Right, the problem is that the other non-cipso system just doesn't know
what to do. On the rhel cipso system, you can set it to accept or deny
unlabed packets, so we do have that option available.
KW: it seems to be that the cipso configured system is behaving as expected
GW: what does the unlabeled toggle do then?
KW: tells the rhel5 system to reject the packet if it is unlabeled. but
there is nothing we can change to make the non-cipso system understand
cipso.
SG: seems that it should be bi-directional to not send labeled packets ...
LS: if you want it to send unlabled packets out you just disable the
netlabel cipso configurations.
KW: I'm not up to date on iptables, but could you also set iptables to
configure it that way, to send unlabeld packets to certain hosts that
don't understand cipso.
LK: I think we should post something so paul can see it and respond
GW: right .. so are we comfortable closing this out.
LK: I think it is working as expected, or as paul intended it for it.
KW: I was just looking and there is an iptables option to configure rhel5
system to stip label based on which IP you are sending to
GW: good so it sounds there is no issue. this one should be closed.
SG: who ever is testing this bug should close it
LS: I can close it and explain we discussed it on this call
223532 nor nor All ASSI [LSPP] crontab manpages reference older
environment variable
IB: naturally ..
SG: this should be in modified state as well
223840 hig nor All NEW [LSPP] getfacl fails to correctly display all
information...
KW: this is actually a very old one. this is not a problem that needs fixing
for evaluation. The getfacl tool is buggy, but the important thing is
that the underlying syscalls are working. just tool is buggy.
SG: we want to fix this once and for all even if it's not required, so it
doesn't come up again.
KW: I posted a proposed fix for upstream and they did something else which
didn't fix it. there are other related bugs in there as well as
reference.
SG: I think the maintainer needs advice on this one. This bug should really
be in "need info" state because the maintainer doesn't know what to do
with it
KW: people need to agree on what behavior they want. The behavior should be
consistant at least.
SG: can you update the bugzilla for our maintainer please with your input
KW: ok
SG: I think he'll fix it if he knows what we want ...
KW: I would like the original fix I posted. I don't know if other people
would like that.
IB: so does this mean we need discusion for that?
SG: klaus will update the bugzilla
KW: I'll add info, but I don't care much since this is not evaluation
relevant
SG: great. I'd like to get this done so we don't get back to it
223864 nor nor All NEW LSPP: Exceptions to expected audit behavior
should be doc...
SG: I'm still thinking about that one, and where to put it.
GW: rhel5 docs is done, so this would have to go in guidance or errata or
something.. maybe man pages
SG: if we put it in man pages then every kernel that goes out I gotta check
to see if it changed. seems to me it might be part of audit docs in
kernel package.
KW: for purpose of evaluation, it would be put in evaluated configuration
guide where all docs that didn't make it in are
EP: aren't these glibc oditties?
LK: glibc oddity was documented in library manpage
GW: weren't there 2 of them I think
LK: yes, I think they went in different places also, there was the off by 1
and by 100 hex
KH: the off by 100 hex is in man page
GW: so we want to documents this as an exception in guidance and RH can
choose to pick up later
SG: it may need to go in glibc. I need to go check on it
EP: I think James Antill is the one that first looked at this.
223894 nor nor All ASSI [LSPP] crontab doesn't report an error when a
job is to b...
DW: I put a patch out for that to the cron maintaner.
EP: I thought you also posted an updated version.
GW: so that's another pacakage we need to carry.
DW: I'll have to check and see if I built it.
SG: it's in rawhide
DW: I need to build a rhel version
GW: another package I forgot to mention is the audit package. we need that
still Steve, right?
SG: yes
GW: ok, I'll add those to my list.
223918 nor nor All ASSI LSPP: audit logs bogus obj label in some PATH
records
LK: Amy she submitted patches for some of these
SG: she retracted them all. We were talking to Al before he sent them to
Linus, and she said she wants to rework them all.
LK: she filed 2 more today so I think she plans to get these out tonight or
tomorrow, since she'll be on vacation after tomorrow.
SG: we'll put Amy's name next to these audit bugs
LK: bug 228386 is the ptrace one. I think it's ok to have her name by
others, but not that one, she is not currently working on it. I think
it'll be good if someone else takes look at it. there was a question
about if audit hooks can be put in place of lsm hooks.
SG: yes, there was discussion on audit list about that
LK: I suggested we start by asking selinux guys about selinux hooks, but I
don't think there was anything done since then, maybe we can get Al to
look at it
SG: I'll see if I can get Al to help. so we'll assign the audit bugs to Amy
223919 nor nor All ASSI LSPP: audit does not log obj label when opening
an existi...
LK/SG: assigned to amy
224080 nor nor All NEW LSPP: audit does not log obj label for
mq_timedreceive/mq...
LK/SG: assigned to Amy
224637 nor nor All ASSI LSPP: Problem SSH-ing into LSPP system with
multiple cate...
KH: we are still working on this one actively
SG: I think that is the same one that Dan was talking about with translation
strings ..
KH: is there reason we see very different behavior on Zseries
KW: comma vs. period thing you mean?
KH: on Zseries, we don't even see the categories
KW: that sounds more serious
SG: sounds like another bug
KW: is there a test for mcstrans
DW: I can work on that
KW: can you make it public, so we can use it as well.
KH: this bug keeps coming back as fixed and I keep seeing it again
KW: the low level functionality seems to be broken. so maybe have some
testing for mcstrans. I think there is little confidence at this point
that mcstrans works correctly.
GW: we had another person confirm the fix and that might have added to the
confusion
KH: seems to have been fixed on all platforms but Z
SG: if the problem is mutated, we should have another bug I think
LK: sounds like we shouldn't try to re-test until there is new mcstrans
IB: so this will be closed and some one will open a new bug
GW: kylie can you open a new bug
KH: yes
GW: thank you.
225328 nor nor All ASSI LSPP: ipsec drops first packet when using IKE
daemon
SG: that one I need to get in lspp kernel. I think patch was accepted.
JL: steve I was gonna ask for your help on that. I took latest kernel and
patched it with the patch form David Miller, I couldn't get it to work
with labeled ipsec first, it just hangs; when I run regular ipsec, it
work. when I was working with it, it seemed fine, but I ran a stress
test, minutes into stress test, I get a kernel crash .. I think it's
crashing in ipsec audit code. it's audit_log_task_context, I am not
really familiar with that code, so I was gonna ask for your help. I
wanted to make sure it's not David's patch (btw .. I am using upstream
kernel), so I just ran Linux-2.6.20 and still got a crash. I'm not sure
if it's ipsec auditing or because of the call ipsec is making to the
audit code.
CH: did you have two problems. labeled ipsec wasn't working correctly then
a crash?
JL: I couldn't even do labeled ipsec and I got a kernel crash. Before I can
proceed, I need to fix this.
SG: so you got oops for that
JL: yeah, I'll send it to you
SG: cause I am looking at that code now and I don't see it referencing any
memory it gets.
JL: me too, I'm clueless at this point. I'll send the oops to you and point
me in right direction.
SG: maybe the current...
JL: part of stack trace was kmalloc and I was wondering about that.. it
crashes on both kernels too..
SG: send me the oops and I think we can take over from here
CH: if you have problem with labeled stuff, venkat can help with that as
well
JL: great, thank you both.
SG: just append it to the bugzilla so everyone can do that
JL: even if it's an upstream kernel
EP: yes, just put it there so we can know what's going on.
SG: we should have separate bugzilla for this also
JL: Eric, you sent me an email about another oops and David Miller is
looking at it. He doesn't like the ipsec audit code. I'll take his patch
and test it. should I open bugzilla for that on lspp kernel
EP: yes, might as well ..
JL: as soon as I get those things done, I'll go back to testing David's
patch. See why it didn't work for labeled ipsec; I am not sure what's
going on since his fix seems to be transparent regarding labeled or
unlabeled.
225355 nor nor All CLOS DUPL LSPP: Label translation not reversible,
causing ssh login...
225443 nor nor ppc NEW LSPP: No console login on first boot
GW: This looks like it was fixed thanks to Linda's work.
LK: I haven't tested the updated policy
DW: I might have missed some stuff, so try it and let me know please..
226780 nor nor All ASSI LSPP: audit of writes to files of bin_t
produces no records
SG: I need to build an audit package and get that for people to try.
227412 nor nor All NEW lspp: /root context isn't right on install
GW: we talked about it a bit last week
KW: should be fixed in latest kickstart but there were other issues, so I
need to make another drop. The workaround is manually relabeling those
directories
LK: klaus, did you see my mail regarding users being set at wrong level.
KW: yes, I saw that, I thought I tested that explicitly, but might have
tested the wrong thing. I'll look into it and fix that.
IB: so is there a workaround for this bug?
LK: we'll have fix in kickstart script.
KW: you can mark it "no fix" if you want it out of the bug list
IB: someone needs to mark it "no fix"
SG: I'll take care of it
227733 nor nor All ASSI [LSPP] unable to ssh into a system as
root/auditadm_r
227889 hig nor All ASSI [LSPP] CUPS is printing with Audit daemon stopped
GW: once I get self tests done, won't this help a bit
KW: I don't think it is a requirement to meet lspp. if admin stopped audit,
there is no specific requirement for action to be taken
GW: I think the issue was explaining it to a creditor
KW: it would be nice to have function to get status of audit as a library ..
SG: it asks that given that failure, what should I do? it would be easy to
make it a library function
LK: to me the real issue is that most things are audited after the fact, so
you can't prevent it, whats the use?
SG: do audit netlink open, see if audit is running
LK: that's what cups does, but things can happen between when you open
netlink and when audit is written
SG: right, but we narrow down the window as a try.
MA: I think it's a case that would happen when using useradd
SG: changing hardware clock
GW: do we need to do anything about it
SG: klaus said from evaluation point of view it meet requirements.
KW: if it causes problems when people try to deploy system, that's something
I don't know about
GW: Casey brought that up .. right?
LK: if audit can't audit, we halt the system
KW: the self test tool panics systems if it's not in a sane state
GW: I think that is what we wanted to do
CH: I think we can use the tools to just start it.. tends to make them happy
SG: yeah, we can do that
GW: what if it's in a bad state, do we try so many times for example
SG: if you try to restart audit and there is a problem it'll tell you and
you can check the return
GW: is it sufficient to just check auditd status or should a dummy log be
logged as well
SG: I think checking the status is probably good enough, since your test
script will run periodically
GW: you can have watcher process on audit
SG: there are people asking about running it out of inittab, it was never
designed to do that. I'm thinking this over to decide if I should do
that.
IB: so what to do with this bug?
SG: I think we can close this as not a bug. this kinda comes back to a more
general issue, we got those library functions added in, and it was added
to cups but wasn't used into anything else
IB: George it was opened by IBM, so should be closed by IBM
GW: ok, fluery opened this, I'll take care of it.
GW: looks like dan already fixed 228102.
LK: I'm guessing this is an issue with how egetty configures the device. I
verified the behavior on that. George in your case, what do you have
agetty or mingetty?
GW: I think it is agetty
LK: if mingetty it can be an ia64 problem.
GW: this is an agetty .. maybe you should try that ... I have not tried a
serial console in a while
CH: we use agetty also, but I didn't think we had issues, we use in in non
enforcing maybe
LK: this is not related to enforcing or not..
GW: I just tried it on a virtual console but I'll try on real console .. we
can verify.. I'll post to the bug whatever result I get.
228107 labels for labeled printing don't wrap
MA: there are other internal buffers that can't handle those longer labels,
I'm going and finding those, once I have all tracked down and fixed, it
should be done. I think we'll need to carry a cups as well.
LK: this is something required for evaluation .. right?
MA: if labels don't wrap, you can loose info about labels, since it can
spill off the end of the page. I couldn't figure out why it was having
problems, it turned out there was lots of 1024 char buffers that I was
passing larger info into.
GW: Ok, miscellaneous issues, I have not done anything on self tests, I am
hoping I can do something this week. I may have a trip out of town for
the next few days. If I make that trip I
should work on it over the weekend. I am still committed to doing that.
Other misc issues?
MT: the issues klaus kiwi had ..
GW: oh, right .. there were couple of issues, one was chcon issue (chcon
file at systemlow to s15, and got denied)
MT: what level was he in? non sysadm can't reclassify info. it's in the
constraints. you need specific privileges to change mls sensitivity of
file.
GW: so not strictly BLP but desirable behavior non the less
MT: because we have the write-equal constraint, we can't do that.
GW: everybody agrees this is desirable. Another issue was being able to
print to files not to
network devices. klaus kiwi sent me this ... unable to print to file
using cups...do we need to support printing to a file
KW: this is using cups to print to file, usually when users are printing to
file, they use
application option and not related to cups. I think it is ok to add an
allow rule for that.
DW: did they use spool_t
MA: I think the other problem is that the check is only checking if actually
allowed to write to char device. allow rule should be $1_lpr_t to allow
for it to do that
DW: we're looking for file type, not char file type
MA: at this time, it's hard coded to be char file. from cups perspective
printing to file is not important
DW: what do you mean?
MA: that has to check the user context and compare it to output device
context.
KW: what do you mean it assumes it. doesn't cups reject attempts if it is
not char device
MA: if avc check fails then cups rejects the job
KW: if there is sufficient policy in place, would it permit printing?
MA: yes ..
DW: I can make policy to make cups do that, the check is a matter of getting
policy correct
MA: check as it is currently is hard coded with char file. cupsd should be
able to write to file even though it's a regular file
MT: does it have policy permissions to do that?
DW: I think I need to look at code, I am not following you
MA: avc-has-perm is using setclass file with char device to setup it's query
LK: maybe let people know that cups does its avc calls itself
DW: the way to get around it in policy is to say user has permissions to use
char file
MA: in klaus kiwi's setup it seems he will already have output file created
except for the right context..
DW: should we fix ..
MA: there is more than just that to be changed to support printing to a
regular file
MT: do we really need this functionality
MA: I thought we weren't going to do it
MT: as this is not really impacting anything
KW: I think this was to test it without having physical printer around, and
having policy to allow that would be fine
MT: so we should a hack policy ..
KW: what you hack up should be shown that it doesn't break system security
and doesn't make results not applicable.
GW: anything else that anyone needs to bring up. ok, I'll get something done
on self test and we'll keep working on resolving remaining issues.
Thanks everyone.
More information about the redhat-lspp
mailing list