02/26/2007 lspp Meeting Minutes:
===============================
Attendees
Robin Redden (IBM) - RR
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
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
Chad Hanson (TCS) - CH
Joe Nall - JN
Agenda:
Agenda and Meeting Formats
Bug Discussion
Around the Room
RHEL 5+ Packages:
kernel-2.6.18-8.el5.lspp.65
kernel-devel-2.6.18-8.el5.lspp.65
kernel-doc-2.6.18-8.el5.lspp.65
mcstrans-0.2.3-1.el5
selinux-policy-2.4.6-38.el5
selinux-policy-devel-2.4.6-38.el5
selinux-policy-mls-2.4.6-38.el5
selinux-policy-strict-2.4.6-38.el5
selinux-policy-targeted-2.4.6-38.el5
audit
vixie-cron
LS: George is still out for a family emergency. We are not sure when he'll
be back. If there is anything urgent you need from him, please let us
know and we'll try to relay it to him somehow. Ok, I saw there is a .66
kernel and Steve saw a panic in that.
SG: yeah, I got a panic as I was rebooting. It may be related to something
new that we added in this build, I remember people wanting to get object
of signals, maybe there is a lock being held too long there. I don't
think anyone reproduced it. Eric was able to crash it in a different
way.
EP: do we have debug stuff turned on?
SG: We talked about that and decided to turn debug option back on. So the
next few kernels are likely to have debug turned on to catch bugs more
easily. I think there is .67 kernel that will be out shortly. same
kernel with debug turned on.
JL: do we have to be doing anything in particular to hit the panic you saw?
EP: I was loading 2 audit rules, one file watch and watching a program, I am
not sure what caused it yet
JL: so we can run some tests on this kernel and try it
SG: if .67 kernel is out of the build system, we can push it out and would
be better to test against it. if you run a suite of tests, you can run
it with that to track memory corruption and leaks and to flush out bugs
that we wouldn't normally catch.
JL: so we should be testing on .67 kernel.
SG: yes
EP: new panic mean there is new bug that's not on the list. You'll get it
next week
LS: oh .. sounds great
SG: this week I think I'll get time to consolidate all lspp pieces to put
them in lspp repository.
ID Alias Sev Pri Plt Assignee Status Resolution Summary
218386 nor nor pow [EMAIL PROTECTED] ASSI LSPP: labeled ipsec does not
work over loopback
LS: Joy you were going to do stress test and send patch to ipsec_tools. Any
progress on that?
JL: I did, everything was great until I noticed something that shouldn't be
happening. Usually I test with ESP since you can do authentication with
that as well. This time I did a test to make it use ESP and AH protocols
in policy to create both of those. This was regular labeled ipsec, and
it was creating double amount of SAs. It only does this when I specify
both protocols. if I specify one, it works ok. I am tied up with another
task until thursday morning then I'll look into this.
223918 nor nor All [EMAIL PROTECTED] ASSI LSPP: audit logs bogus obj
label in some PATH records
LS: Eric said this fix was in .65 kernel. Amy opened it .. has it been
verified anyone?
EP: Yes, it's in there, and I'd like to hear from HP.
AG: have not verified since I've been out on vacation. I'll test it in lspp
kernel and verify
LS: great, thanks Amy
223919 nor nor All [EMAIL PROTECTED] ASSI LSPP: audit does not log obj
label when opening an existi...
LS: This also was opened by Amy.. do we have status on this one?
EP: same deal as the one above.
AG: Ok, I'll check both.
225328 nor nor All [EMAIL PROTECTED] ASSI LSPP: ipsec drops first
packet when using IKE daemon
LS: Joy, what's the status on that one. You were talking about trying the
upstream kernel.. did you get chance to do that?
JL: I tested in .65 kernel. so far no problems. I was testing in ipv4, and
still need to try ipv6. I'll start some stress tests tonight. I tested
regular and labeled ipsec in ipv4, with loopback also and so far all
looks pretty good. ipv6 remains, I'll do that with .67 kernel and see
how that works. It's been looking pretty good otherwise.
228366 nor nor All [EMAIL PROTECTED] ASSI LSPP: audit does not log obj
label for signal recipient
LS: we have patch in .65 anyone verified it?
EP: this particular one was not in .65. It shows up in .66 and .67, and
might be the cause of panic
LK: I just loaded .67 kernel and it panic-ed. I loaded a watch and it
panic-ed.
SG: I think this is a patch that we still need feedback from Al on. I talked
to him last week, he was gonna look at this. I'll ask him again.
LS: ok, thanks steve.
228384 nor nor All [EMAIL PROTECTED] ASSI LSPP: audit does not log obj
label for traced process
LS: status on this one?
EP: need Al's feedback as well and this one does not have a patch.
SG: Al said it should be simple to do. I did not see a patch for it. When I
catch up to Al, I'll ask about this patch and see if he got it done.
LS: ok, thanks Steve for following up.
228422 med nor All [EMAIL PROTECTED] ASSI LSPP: cleanup xfrm_audit_log
interface
LS: Joy you opened this bug. I think this one you said David Miller posted a
patch for.
JL: I think .65 kernel did have that patch in it. again, since it was in .65
and I tested it, I think it looks pretty good. I have a question about
this one and the bug about ipsec dropping package, these were opened in
reference to upstream and lspp kernel, should I be testing both in
reference to RH bugzilla
EP: I would like to hear all info, but what mainly matters is lspp.
SG: if you test the patch and it works ok in lspp, I would re-diff it for
current devel kernel and check it quick and send upstream. Even if we
have them working on lspp, they need to go upstream. we have lots of
bugzillas open and we need their patches to be accepted.
JL: this bug was initiated upstream..
SG: we should be covered then. If it was an upstream accepted patch and was
back ported, then we are ok
JL: so should I look at both
EP: in most cases, you want to look at both of them. If you really hammer
one and lightly test the other it's ok too
JL: in lspp kernel this looks good.
228557 med nor All [EMAIL PROTECTED] ASSI LSPP: In labeled ipsec,
permissions are checked after del...
LS: Eric you were working on a patch for this one; any updates?
EP: there is patch in lspp.67 kernel and I still need to send it upstream
LS: joy did you open it?
JL: yes, I'll test it as soon as I get .67 kernel. After I run stress test
we can close them out.
EP: don't actually close them, just put comment that you tested and it
works.
229094 med nor All [EMAIL PROTECTED] ASSI LSPP: audit records for some
f*xattr syscalls don't inclu...
LS: Looks like there was a patch and linda tested it
LK: yes, I tested .65 kernel and it works.
LS: should we change status on these bugs?
SG: What will happen is Eric will post a patch internally, then the bug will
go in our bugzilla system and status will be updated.
EP: there are number of these bugs that need to be upstream and we need to
keep them on my radar, so we don't want to close them yet.. maybe we can
put them in a separate list but that way they stay on our radar.
JL: does it help if we can just put more info in the bug.
EP: yes, as you test, just update the bug with the results
SG: Eric, we can put the bugs in a "need info" state.
229527 med nor All [EMAIL PROTECTED] ASSI LSPP: flow cache entries
remain valid even after selinux ...
LS: Eric opened this. status?
EP: This came from venkat and I'll get some testing on it
JL: not sure how to test this one, I can send venkat an email to ask him
about that
EP: if you can test it, I'd appreciate it.
JL: I'll send him an email and ask him cause I'm not really sure.
229528 med nor All [EMAIL PROTECTED] ASSI LSPP: memory leak in flow
cache code
LS: Eric, status on this?
JL: This is another one I can ask venkat about. I'll ask him how to test it
as well
EP: might be just a code inspection.
JL: I'll ask him.
223532 nor nor All [EMAIL PROTECTED] ASSI [LSPP] crontab manpages
reference older environment variable
LS: there is a note that says this should be changed to modified. not sure
who needs to change it.
SG: Dan put it in his page for people to check it and will try to get it in
the lspp repository
226780 nor nor All [EMAIL PROTECTED] ASSI LSPP: audit of writes to
files of bin_t produces no records
LS: Steve talked about this last week. There is a fix.
SG: I'll try to collect that one up and get it in lspp repo later this week.
228398 med nor s39 [EMAIL PROTECTED] ASSI LSPP: Not able to ssh into the
machine with multiple cate...
LS: We talked last week that we should be using raw context instead. did
Tomas have any time to look at this?
SG: I think he split this into a new bug, since it is two problems. The
original is mcstrans, he opened another one to fix a problem when the
number of categories is too much. I think he has taken a suggestion from
the bugzilla and started working on the code. I'll follow up on that and
if there is package I'll put it in repo as well
IB: it is marked as modified.
SG: he changed the state just an hour or so ago
LS: do we have the new bug number.
IB: 230120
229278 urg nor All [EMAIL PROTECTED] ASSI LSPP: ssh-mls allows a level
through that it should not
LS: This was raised to urgent and I saw notes back and forth on the bug ..
what's the verdict on this one?
JL: Dan are you there? I'm not sure what to make of the comments
DW: problem is the way we are running sshd. I don't know if it is that
critical.
JL: is it not considered security if someone s2 is allowed as s3? klaus was
mostly concerned with that one.
KW: the issue is there, ssh has override capabilities, it is up to sshd to
enforce restriction on that. can't expect policy to enforce
restrictions. It's a matter of opinion if you want code to be in sshd or
a library. I think it would be cleaner if utility function returns the
decision, but you can have sshd do the check
DW: I think sshd should do it
KW: having sshd do it should be appropriate. I think it is up to sshd to
make sure it does the right thing.
CH: stephen is apposed to having it hard coded
KW: I am not sure this is really an mls things. if utility function decides
to adjust level, it is not just an mls thing, it might not be
appropriate in other cases. I don't have an opinion in where it should
be fixed, but stephen's comment is correct that we can't expect this to
be rejected by policy
DW: this is an issue of labeled network. you are requesting context and if
it returns something you don't expect it should deny it.
JL that would require knowledge of who the user is though .. right?
DW: does ssh make decision or libselinux. libselinux returns something
different than what you asked for, then you should deny it.
KW: what gets returned is definetely wrong in an mls environment, not sure
what classes this covers in general. and it's a bit different from what
is expected. I think sshd would need special case to reject that. a
simpler case might be more appropriate to not use range at all. so just
request lower range, and send that to selinux function.
DW: why is network ranged anyway
JN: right ..It think it shouldn't be ranged
KW: in mls environment you normally want to look at low end. In current
operating mode, you could actually use the range, but only restricted to
trusted people and it is not necessary to have that capability.
DW: how does network get a range in first place
JN: coming from sender side
KW: on sender you have ssh client and it has clearance range that the socket
inherits and ssh uses that range, joy correct me if I'm wrong.
JL: yes, it's correct
KW: what should happen are enforcement rules and they should look at
effective lower level. There are only few tools that look at user
clearance like newrole. I think it's easier if you have behavior like
cipso where you use low level. however, ipsec is designed to do ranges.
JL: would it be better if labeled ipsec would take effective level
KW: would be easier in mls environment, so whenever you have policy
enforced, the right thing will happen. in this case it is trusted
application not restricted by policy
JN: I thought we need ssh to have a new domain, but you need it for
polyinstantiation
KW: yes you do, you can do domain with less privileges. I thin sshd need to
stay a trusted application.
LS: what's final verdict
KW: sshd only uses low level instead of range.. so it can truncate the
range. it would also work to have ipsec not use ranges but it's a more
invasive change.
JL: should we think about it for later on
DW: should we do it at a lower range or just have it compare the context you
get.
KW: ..
DW:
LK: was chad advocating the no ranges
CH: I am torn, the range on ipsec doesn't make sense. it works when you try
to transfer user clearance. usually a network is a given label. it could
be useful.
JN: there are places in our code that we look to see what user clearance
are. most time we have other mechanisms to do that. In our case, it's
not a single level network, but each connection should be.
LK: if we change the behavior, it's better to change it now rather than
after evaluation.
JN: if we go forward, are we going to use ipsec to deal with mechanism ...
JL: are you talking about ipsec over loobpack
JN: the loopback is kind of bandaid to me. it is a high overhead way to do
local networking.
JL: thursday would be my priority to get it 100% working
JN: right now you are talking about low latency connection, you get kicked
out to daemon. it is really high overhead stuff. I don't think it's a
long term solution
CH: we want to get those resolved as well, it won't be immediate. we need to
resolve this instead of ..
LK: is this a topic for developer summit ..
JN: if mechanism we have passes clearance, then ipsec should for
consistency. something to think about as you think about this problem
CH: is it really user credentials or labels on package. traditionally you'll
write something on file with label. user has effective label and
clearance. so that's part of the issue.
JN: I guess I wouldn't change anything at this point. change this in ssh now
util we come up with a solution.
EP: i think everyone who deal with labeled networking, problem is there is
no real solution right now.
JL: for now, it's ok that it passes range instead of effective level
LK: sounds like sshd would need to do the right thing.
LS: who would work on this
DW: we will
SG: between Dan and Tomas we'll work on having something.
LS: great .. thank you
228107 nor nor All [EMAIL PROTECTED] ASSI [LSPP] Labels for labeled
printing don't linewrap
LS: Matt was still working on it. Any status on this one?
MA: the patch is coming along, still having trouble with post script. I have
it most of the way, but having a bit of trouble. I need to adjust some
values. I am most of the way there, need some final testing.
229673 urg nor All [EMAIL PROTECTED] ASSI [LSPP] cups is overriding mls
when querying jobs with lpq...
MA: I believe I have patch for that finished off, need a bit more testing,
that one should go to RH today, and other one (above) should be done
this week as well.
229543 med nor All [EMAIL PROTECTED] NEW LSPP: odd avc message
LS: opened by Kylie. Stephen Smalley said it was not a bug. Kylie did you
get a chance to review and decide about this one.
KH: we understand what's going on. klaus and people on other side, said they
didn't like behavior
KW: I don't really like way it behaves, but it's not a problem
JN: what info were you trying to capture from avc message.
KW: there was no capture of state
SG: problem is inconsistent
KW: that requires some explanation. CAPP require an audit record for a
relevant action with a success/fail state. and you don't get that in
this record.
SG: out of curiosity. are you keeping list of things that can be done better
for next time
KW: I'm not keeping list
SG: at some point in next few months, I think it'll be good to keep list of
that and discuss those issues
LK: need to look at things that were closed as not a bug, since those will
indicate confusing issues that can be improved.
SG: for example we use killall as way of revoking user, better to have
revoke syscall...things that meet certification, but that we can do
better.
LK: can get feedback from Joe and what things they are working on
KW: It is important to hear from people who use this system to see how it
meets their needs. For example, polyinstantiation has usability issue,
and if we get feedback we can see how it worked
SG: polyinstantiation needs some help. I would like to hold a conf call
sometime in future 2-3 months from now to talk about things that could
have been done better, more usable and things we can improve.
KW: we can have something like that at the linux symposium.
SG: not be in developer summit ..
LS: get it on list to get feedback from others as well
SG: yes, later down the road, now people are busy. but definetely want to
hold this discussion. and would be open to mail list and people of
teleconf. SElinux symposium would be a good start point. FC8 will open
soon and we need to start to get things in there, that would be probably
around April.
229720 med nor All [EMAIL PROTECTED] NEW LSPP: pfkey_spdget does not
audit xrfm policy changes
LS: Eric opened on 2/22, any status?
EP: both (below as well) should have patches in .67
JL: I'll test that kernel and see.
229732 med nor All [EMAIL PROTECTED] NEW LSPP: pfkey_delete and
xfrm_del_sa audit hook is misplaced.
LS: Eric, any status on that one too.
EP: same as above
223864 nor nor All [EMAIL PROTECTED] NEW LSPP: Exceptions to expected
audit behavior should be doc...
LS: Klaus Weidner was going to modify the guide to add this info. Any
status.
KW: I added some parts to it, will make sure to complete it.
KEW: should we also document 229543 ..
KW: yes, I'll add that also
228927 med nor s39 [EMAIL PROTECTED] NEW LSPP: odd audit argument on
some 32 bit syscalls
LS: Agreed that this info should also be in the config guide.
KW: also documented.
LS: should they be closed...
KW: this is for th IBM config guide. it is appropriate to say they have been
documented, but others need to also document it.
LK: I'm making a note of these two
LS: Kylie, can you verify that the info added is what you needed
KH: I can you verify, but I can't close it on RH
IB: you can write a comment in there, and we'll update it.
223840 hig nor All [EMAIL PROTECTED] NEW [LSPP] getfacl fails to
correctly display all information...
LS: Steve said that acl-2.2.39-2 is built with a fix. Klaus kiwi put a note
today asking if there is a .el5 version of the acl package we need to
pick up. where do we pick the package from?
SG: yes there is one, that should also be in the repo that I'll create.
LS: I have a couple of questions to bring up, first is regarding the audit
package, should we be picking the latest audit from Steve's page. Last
week Steve you said there were few fixes you were going to put in (the
-se fix was one we needed), what package version should we have?
SG: you need the latest package in the 1.3 tree.
LS: I saw a 1.4 package on your page, so we don't need to pick that up
SG: no, that has more changes, I've hand picked few bug fixes and been
porting them back to 1.3 branch
SG: did we talk about oops that joy found two weeks
JL: I am so glad you mentioned that (audit_log_task_context). I found it in
upstream kernel and didn't see that in lssp kernel. Al was looking at
that, but didn't see information about it
SG: he put a patch out, but it went to selinux mail list I think.
JL: to test that one, I can pull upstream kernel and test. Is it ready for
testing?
IB: if you know the bug number, let me know and I can add it to this list.
JL: Let me try to find it (228409)
SG: I can give it to Eric and Irena later if you can't find it.
KH: Dan you tried to explain on IRC, why a unix read on shm (read down)
would fail. we were getting "fd use constraint". we were confused.
DW: you are passing it to file process, and were trying to use it for
communication.
KH: we are able to use getattr correct though
DW: getattr is not passing data.
KW: ..
DW: maybe it's right error, but fd was not closed on exec.
KW: there seems to be perm denied only. in that case it is correct
DW: it was shm unix write denial.
LS: Any more issue we need to talk about? ok then, we'll adjourn. thanks
everybody.
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
