Note: I think I mixed up people's voices today, so apologies for that. Feel free
to correct me if I mentioned you said something you actually didn't
09/18/2006 lspp Meeting Minutes:
===============================
Attendees
Robin Redden (IBM) - RR
George Wilson (IBM) - GW
Loulwa Salem (IBM) - LS
Michael Thompson (IBM) - MT
Thiago Bauermann (IBM) - TB
Al Viro (Red Hat) - AV
Irina Boverman (Red Hat) - IB
Steve Grubb (Red Hat) - SG
Dan Walsh (Red Hat) - DW
Linda Knippers (HP) - LK
Amy Griffis (HP) - AG
Matt Anderson (HP) - MA
Paul Moore (HP) - PM
Klaus Weidner (Atsec) - KW
Darrel Goeddel (TCS) - DG
Chad Hanson (TCS) - CH
Venkat Yekkirala (TCS) - VY
Joe Nall - JN
Ted Toth - TT
Bill O'Donnel - BO
Tentative Agenda:
Kernel / Rawhide update
------------------------
GW: Al, anything we need to know about the kernel?
AV: no. there have been final patches given for hookups on targets into
mainline kernel. All arch dependant changes are in mainline now. One
question, do we care about stuff like solaris binaries?
KW: yes we do care. if there is a way to disable these binaries. Main thing
we don't want a user to run them without the admin able to stop them.
AV: yes, there is a way to disable it
KW: how do you recommend we do that?
AV: disable them at build time
KW: the problem is that people running the evaluated system don't build
their own kernel.
AV: there was alot of use for the binaries. there has been some support to
at
least a subset of syscalls.
KW: is there an easy way to tell at run time which personalities are
available for binaries?
AV: yeah probably
KW: ok, thanks
AV: if we do implement this at some point, we'll need to think about adding
those new audit fields. right now there is a constant for architecture
and they really should be different. creation is not different, they
should be just treated as separate archs.
KW: I agree with treating them separate. main question is if people have
interest. it's up to arch maintainer to see that audit works, so it
might be a similar logic for this one.
AV: this can be interesting. keep in mind it is not just kernel; user land
has to understand those as well.
GW: is this going to be an issue on rhel. can we prove to evaluator that
binaries are not enabled?
AV: This is not an immediate concern, maybe for future. really we'll best
make sure those are disabled. I'll put it that way, I wouldn't rely on
correctness of code.
KW: maybe if people start adding this to the kernel then it'll be good to
have one place to control it.
AV: I don't think so. It is not a real concern. I don't believe anybody is
using that on a production type system
KW: what I was saying is that if it ever gets to a state where it is used,
it would be good to have run time option to turn it on/off.
GW: klaus we need to demonstrate that to evaluator?
AV: which archs?
GW: s390 and ...
KW: RH doesn't ship with binary compatibility enabled.
AV: we'll have support ...
LK: the support for 32/64 is not in kernel by default
AV: for audit enablement it shouldn't be a problem
KW: it's not easy to test it actually works
AV: handling of binaries is concerned on alpha, sparc and ... as far as I
know.
GW: sounds like we don't have a problem since these are not part of TOE.
good news.
AV: the kernel should be basically done
GW: ok great. Any one has any more issue
JN: I was having a problem with (a package?), what kernel is it in. Stephen
smalley was saying it'll be in 2.6.19, but that's not the naming
convention rhel is using?
SG: those are release candidates, sort of mislabeled. it really is the
2.6.19 release candidate 7.
JN: Ok, I was a bit confused and was trying to figure it out.
SG: because of rpm, it is one version behind
JN: when you ship it'll be 2.6.18?
SG: yes. speaking of kernel, we have one bug (the audit by ppid problem).
GW: does it still look like a user land problem?
SG: can't tell. I ran pid and ppid value and it looks like it's builidng the
same packages. other than that it's the kernel that evaluates that rule.
As far as I can tell, user space is acting correctly, and so is the
kernel
AV: .....
SG: audit by ppid is only thing that doesn't work.
AV: pid works?
SG: audit by pid works, audit by ppid doesn't seem to work
LK: is there a bugzilla for that
SG: I asked mike to submit one
MT: I submitted one, I'll check if it is on issue tracker
SG: just so we get it, you can file against rawhide. as of Friday it is in
sync with lspp kernel. I am looking for this bug, but it would help to
have another set of eyes searching for it as well.
AV: if you add negation which test does it take
SG: if I negate it, it takes the proper one. It's really strange. I am
building a new kernel to see how it gets evaluated
AV: yeah, that's what I would do, to see what happens
SG: yup
GW: does this happen on all arch
SG: on x86_64
MT: and ppc64
GW: alright, as for IPsec, I don't know if Joy had another ipsec patch out.
MT: I have update from Joy, she said she sent a status update to lspp list
about racoon. also a patch for ipsec, there is a bug in it, so she is
currently working on fixing that and will send an updated patch.
GW: has she posted a right up about that?
MT: she said she'll add docs to what venkat sent out once she is done
working on the bug. Not sure if that is what you were looking for?
GW: It is .. great. ok, any other kernel issues? I know we need that
networking section to test for bugs there as well.
SELinux base update
-------------------
GW: any selinux updates
KW: one issue, selinux users mention that 256 categories is not sufficient.
Any thing happening in there?
DW: what number do you want
GW: I believe it was mentioned to raise it to 1024
DW: we'll just update the policy, add the lines for the new categories.
KW: I grepped for it, and found the limit mentioned in few places, so it is
not only adding lines to policy I believe.
DW: so we'll make it 1024.
CH: great, because I currently exceeded that in some of my tests, so it's
great that we are adding more categories.
JN: I beleive there is a place where it is 239 limit in CIPSO.
TT: you can have so many comparetments. The way netlabel gets around that,
you can setup mapping, you can have one cipso DUI(?) that allows you to
map certain ranges of levels. if you care about that, send me an e-mail
and I'll show you examples.
KW: what's the failure mode case. so that MLS restrictions are enforced?
TT: if you can't guarantee labels on that. if you are doing accept it'll
prevent you to write to that socket.
KW: so it'll do the right things
TT: hope so
GW: looks like it need testing. I've seen a few other problems. There is no
login prompt on console. Has anyone seen that?
DW: after coming back from suspend mode?
GW: no, on a fresh instal with MLS policy
KW: is there an AVC message?
GW: I need to check that
MT: I've seen it happen as well
GW: I'll test more, but just wanted to check it is not something I am doing
before I open a bug
DW: so on a fresh install you see it. sounds like a bug.
GW: Another thing, if I create a user and try to change thier password, then
I get a pam error.
KW: there is a problem because of using the passwdqc module. that has been
changed recently.
DW: it is not selinux related, happens even in disabled mode.
KW: there is a bug for that, kris opened it. This is not a very debugging
friendly problem, the message is not very indicative of what's going on.
TT: did you use useradd -m, that works for me.
KW: the bug number is ( RH - issue tracker # 102108 )
GW: does every one have visibility to bugs
IB: probably not, I only opened up one bug. I'll go through them and make
them public.
GW: ok, I have no objections to making them public
IB: before we send them, I'll send list to IBM
GW: Anyone sees more strange behavior?
MLS policy issues
-----------------
Audit userspace
----------------
GW: Steve, is there an update for audit user space?
SG: I'll push audit-1.2.7 out overnight. to match 2.6.18 kerenel and various
fix ups
GW: should we pick it up through rawhide, or will there be an update repo
SG: should be update repo, but not sure
GW: ok, so we'll pick through rawhide. Thanks Steve
Print
-----
GW: Matt, how's print?
MA: It's coming along. After seeing Rodrigo's message, I am a bit concerned,
since previouly I didn't have access to usb printer. Now I have access
to one, and I configured it through the graphical interface that came
with rhel, so I am getting different info about the device. I am working
on that, assuming all is cleared I plan to have an updated patch this
week
GW: great, thanks Matt.
CIPSO
------
GW: Any CIPSO updates Paul?
PM: working on finishing up a patch to change way of how net label uses
netlink, to make it more consistent with kernel. all the code is
basically written, but still looking through to debug. Few things popped
up last week and I'll submit those fixes. also there is talk that I
need to add audit messages to some places in the code to satisfy
evaluation requirements.
GW: what type will these be?
PM: These will be shown when you configure netlabel.
GW: will these be of new audit types
PM: I imagine so, but I didn't get a chance to look at it closely.
LK: this is to any security related changes to netlabel?
PM: yes
[Klaus came back with Pam bug number - conversation switched back to bugs
tracking]
IB: if you put lspp in subject line of the bug, then I'll pull it in my
search and I'll make it public. if you are a member of our beta group,
then you'll be able to see those bugs. Linda is a member, george is not
for example. It's easier to make bugs public rather than to add everyone
to the beta group
GW: can you add me to beta group at least Irena, but I think it's good to
make them public. My question, once there are change updates, how does
the originator find out.
IB: you won't get bug number, but you'll get the comments that people post.
GW: Ok, that works
IPsec
-----
GW: so Micheal gave us Joy's status. Anyone from TCS or Venkat if on can
give us further update.
VY: I am on george. I am waiting on Joy's racoon patch to test that, then
I'll send my kernel patch out. I heard that the version she sent out had
a bug.
CH: Venkat didn't hear what Mike said about Joy's status so I filled him in.
MT: Joy said she had a patch, but it has a bug, that's what she is working
on right now, she'll send an update to that patch with the fix
VY: I'll test what I have and send my patch out. did she say when the fix
will be sent?
MT: She said "later" so I don't know exactly.
GW: good idea to send what you have now. I'll talk to Joy and get a read on
her status as well.
IB: I am concerned how our fixes are going to make it to beta 2. Those
patches need to be accepted by upstream and bugzillas opened so that
they are managed by rhel as soon as possible in order for us to get them
in. keep that in mind.
GW: who need to open those
IB: who ever is submitting those patches. maybe as soon as they submit to
upstream, they need to create a bugzilla. so james morris knows what to
look for and pull in.
GW: Venkat, do you have an idea on when you'll be done
VY: I am going to work on comments from Stephen smalley and I'll work on
those and get those in next week or so. I'm planning that secmark
patches being accepted. I'll get that in next couple of weeks. Need to
get people to do design and docs. we had a question from Dan walch on
how all of this is going to get integrated. I would guess in the next
two to three weeks we'll have all those issues out of the way, and get
buy in from people.
SG: when you say couple of weeks, you mean 2 weeks?
VY: I would say 2 to 3 weeks
SG: we can't drag this after end of September, or they may not make it in
beta 2
VY: for secmark that's a big one, we have some useful feedback now that we
can act on. once we go through feedback, it's a matter of integrating it
in and sending another set upstream. I say we are close for secmark,
within next week we'll have issue resolved. I'll send the ipsec fix out
tonight.
DW: are you working on performance on secmark
VY: We didn't check performance, just looking at functional right now
DW: I just have usability concerns. I don't find secmark very usable. I
don't like the interaction between policy and secmark.
VY: I guess in next couple of days there will be a good amount of
discussion on these aspects.
DW: I heard there will be a big performance problem with loading iptable
rules. this secmark stuff really need to be looked at
GW: should we be using the compatibility mode then. may save us all a lot of
headaches if we use the compatibility flag.
DW: I just see huge problems with this, it is not very well thought out. the
tools that generate secmark rules, they go through all ports. we have
about 400 rules and you go through all of them before you go through
ipsec rule that might drop the packet
GW: problem is that it is coming in late.
DW: the other problem is I'd like to have a tool that admins can run to set
this thing up.
GW: we need to keep an eye on that and have compat as backup plan
SG: I have a feeling there is real good chance it won't make it
VY: we'll have discussion in next couple of days. Dan already sent out
email.
GW: sounds like we are heading to compat use
SG: I'll take action item to look in RH to see where that is going.
GW: thanks Steve, and I'll do some research. thanks Venkat for the update.
xinetd
-------
GW: any issue with xinetd. anyone testing with it
JN: we've been testing with it. the netlabel stuff doesn't work with
unlabeled host just now
CH: yes it does Joe.
JN: in a reasonable plug it in and run, it's tough without policy
modifications
CH: yeah, you do need to do some policy work
GW: sounds like we might need to make some testing on that. certainly need
some end to end testing in our environment as well.
ipsec-tools: SPD dump and racoon base + MLS
---------------------------------------------
GW: I'll get hold of Joy and see what's happening with the bugs and get more
documentation from her as well.
Single-user mode
-----------------
GW: did single user mode make it?
DW: I'll have to check
Self tests
-----------
GW: I have done nothing on, had some personal issues to attend to.
VFS polyinstantiation
----------------------
GW: don't know anything on those. anyone has update on newrole issue. there
was debate on selinux, might have been resolved but I didn't follow it.
DW: it is not resolved as far as I know.
CH: folks are working on it are writing up their issues.
GW: write bugzillas and submit to list. if we don't get visibility for bugs,
then write a note to list. so we are not all hitting the same problem
and writing same bugs. I appreciate you doing the testing. if they are
minor issues, we might be able to bug janak with them.
GW: any other issues, if not we'll adjourn meeting. Thanks everyone.
Cron, tmpwatch, mail, etc.
--------------------------
Bugs / remaining tasks
-----------------------
Final cutoff date
-----------------
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
