02/05/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
Lisa Smith (HP) - LMS
Linda Knippers (HP) - LK
Matt Anderson (HP) - MA
Paul Moore (HP) - PM
Klaus Weidner (Atsec) - KW
Chad Hanson (TCS) - CH
Joe Nall - JN
Ted Toth - TT
Bill O'Donnel - BO
Tentative Agenda:
Kernel / Beta / rawhide update
===============================
GW: we are still waiting for a few more people
LK: while waiting, Klaus you took autorelabel out of kickstart script, and
now I see problems with the labels
KW: haven't seen those. Apparently there should not be need to relabel
twice, we should look into why it is wrong in the first place.
LK: labels on /root and home directory doesn't work
GW: how do you know it is not relabeled?
LK: if you relabel, it shows they are being relabeled again different than
what it was.
MA: I saw a similar problem with /home directory also
KW: individual home directories?
LK: yes
KW: it uses user management tools. In previous version, it did a relabel
after that.
LK: there was a bugzilla where adduser and semanage are two different tools
DW: how are you adding user?
LK: useradd
KW: I need to read docs on that
DW: use useradd -z <username> and that should get file context correctly.
what context are you getting on home directories?
MA: user for ones that should be staff I think.
LK: I filed bugzilla specifically on /root. I think we are seeing this now,
because the script used to do autorelabel again and now it doesn't
DW: how are you relabeling in the kickstart.. using fixfiles?
KW: fixfile -f
DW: that might be a problem. I think it does not touch user home directories
KW: they don't exist at that point yet
LK: but /root should
KW: currently it uses useradd then semanage login
DW: you can't reverse those, but use useradd -z
KW: how about the -m flag to modify in semanage
DW: you can use semanage afterwards, the labeling on home directories
shouldn't affect that. if root directory is not fixed by fixfile then
restore that directory
KW: I used restorecon on individual files
LK: that's what I did as a work around
MA: can you do that on /home as well
KW: yes, ok
LK: should have been created as part of install?
DW: sysadm needs to relabel.
GW: alright ... so other issues with kickstart, build or kernel. I presume
we still need lspp kernel, and we have to force install it.
SG: yes. from this point you will use lspp kernels. I think there will be at
least .65
EP: what do you mean you have to force install it
LS: it says current kernel is newer than what you are trying to install.
SG: I will look at it.
EP: what kernel were you using originally?
GW: the latest 01/26 I think
EP: I'll look at it
SG: we will have opportunities to build new kernels. we'll clean it up for
the new patches.
GW: so kernel, policy and mcstrans are only packages that need to be
installed
SG: you're talking about snapshot
GW: release candidate is what they call it here
SG: I'll get everything into lspp repo to streamline
GW: I was suggesting we keep list of packages we need
SG: I was gonna suggest we revise this teleconference to be listing of
bugzilla. development is finished and we are focusing on bugzillas now.
if anything new comes up it should become bugzilla to get on the agenda.
GW: is everyone fine with that
SG: Irena has a way to track bugzilla and we can collect everything we need
to talk about. Based on that bug, I'll track what needs to go in the
repo
GW: do you want to start that today?
LW: is it going to be tabular format or text
GW: this is the list that Irena created for us
LW: are we going to have a list or tabular format
IB: I'll have a list of bugs. I'll send it Friday night and George can
re-publish for the meeting
GW: we'll work from Irena's list and any new issues that people want to talk
about we can add that.
SG: there will always be discussion about using the system. I think we are
at a point now to start going over bugs.
LK: there is even bugzilla for one just discussed.
IB: I was thinking we can use partner server for packages. I was looking at
repository for that.
SG: when we get close to end, we'll put it there
IB: ...
GW: from what I am hearing .. Steve you will provide repo off your people
page then near the end it will be put on partner site so we can verify
it
SG: yes, I started cleaning lspp repo. this week I should be able to collect
everything and get scripts to automate pushing packages there.
SELinux base and MLS policy update
==================================
IPsec localhost, IPv6, 1st packet drop
======================================
GW: I have bug a list infront of me, I can hit some bugs while having this
discussion. one of them is labeled ipsec does not work over loopback
JL: I tested with it, regression and stress test went well. Only thing I saw
was the error message occurred every time an SA had to be re-keyed. I
need to look into why that is happening. Paul won't have time to doctor
the patch, when I have time, I'll look at it. if I can fix it then I'll
go ahead and submit to ipsec tools list
GW: Another issue, problem ssh into lspp system with multiple categories,
Dan posted mcstransd for that. Also, ipsec drops first packet (bug #
225328)
JL: David miller put a patch and james miller is happy with it. he has v4
and v6 version for it, so I'll try it
SG: patch I saw on netdev looked like it had bug in it. looks like he
created flag variable but not sure if flag got used
JL: he just posted message
PM: Steve he fixed that.
JL: he put updated version in net-2.26 tree. I'll take the patch and patch
our lspp kernel and see what happens. I don't know if I should test on
lspp or upstream first
GW: probably both
JL: I'll test lspp kernel first and tell him because of priority issues.
unless I can do both at same time on two different machines.
SG: let us know and I'll go ahead and get a .65 kernel so everyone can test
JL: ok, I'll do that
GW: so is 224637 a duplicate of 225355 (labeled translation causing ssh
login failure)?
DW: same problem
GW: ok, so I'll remove one
SG: I think Eric Paris found duplicate bug on msgqueue
EP: don't think they are duplicate, but same patch should fix both issues.
GW: anything else on networking
JL: nothing right now. stress test is ok. I tested loopback and labeled
ipsec with v6. I'll continue from there.
Self tests / aide
=================
GW: As for the self tests. my approach won't work, what I am thinking is
having two instances one at systemhigh and another at systemlow and have
them independently. Anyone has better approach. The runcon approach is
basically trying to validate context. I can newrole into the context but
can't get to it non interactively through runcon
LK: what are you trying to test?
GW: BLP which is a good thing that it won't let me. I want to be systemlow,
write a file and verify I can read it at sytemhigh but inverse is not
true.
LK: does it have to be a file you created. maybe you can be at middle level
and try to read/write files already existing
GW: I could do that and have one time setup and create files then execute
against them. I found that changing levels is difficult. I will have to
do file setup ahead of time
LK: when talking to dan about runcon before, he suggested using newrole with
it. would that work?
GW: I still need a password
DW: You could set newrole_pam root_ok to avoid needing password
GW: I think we don't want to do that though
KW: I think from evaluation point of view it's ok, we assume trusted admins
MA: doesn't root_ok only take affect if it is coming from sysadm_r. so it's
not a big hole as we thought initially
DW: yes
LK: what does Joe think
DW: all the test you are trying to do is 2 different processes running at 2
different levels can't communicate ... right?
GW: yes
DW: I think the bi-level would work
GW: I was trying to do that
JN: that seems to work for me, sorry I checked out looking at some patches
DW: I think we can write policy to have 2 init script to do this
GW: so you use init to start them off
DW: have two init, one that transitions to systemhigh and one that stays
low, and have them communicate
GW: I think this is what will work. I feel current approach won't work. I'll
try the split approach then.
SG: how will they communicate?
GW: sockets, signals or files. I was trying to make it simple and throw it
out there for people to see.
SG: I think if you use abstract namespace then there is no chance of someone
being able to tamper with files
JN: can you explain that, I don't understand the abstract namespace
SG: the abstract name space will only be accessible to the processes only
GW: unnamed things instead of named things. sockets would work
DW: I was thinking systemlow opens listening socket and another one tries to
open socket as systemhigh, and read temp files
GW: right, if I can get approach working we can test multiple things
SG: is /tmp going to have problems with polyinstantiation?
GW: I put them in /var/run .. do you think that is abusable
SG: I remember the amtu that caused problem
KW: /var/run is restricted to root, so I think exposure is pretty small
GW: that's what I was thinking. I'll try that and let people look at it. if
you have other ways or additional things we can add. The approach needs
to be fixable. I'll try that. if Stephan is around I'll ask him what he
thinks about it. Then I have to decide how to invoke aide from that.
Might have 3 separate tests. it won't be a nice clean simple script as I
hoped for
DW: you can do all of them from same initscript
JN: is this going to run on boot or periodically
GW: both. to satisfy RBACPP self test requirements
SG: I think it will be a cron job.
JN: ok, then cron. is there specific requirements for RBAC or is it open?
GW: it is open, but I think we should make it useful. basically we check to
make sure configuration is ok and we use aide to do that.
KW: I think at lease it needs to check if we are in non enforcing mode or if
policy is not loaded.
GW: I'll use aide separately. would it be possible to use init in cron job
to invoke this, or should we have them as long running processes .. if
so I need to get timing variables in there
EP: I think it needs to be cron from what you are saying
LK: can amtu be there also and you can choose to run it if you want
SG: I was thinking to have it something that is run on demand and people
can
set it to run as they need.
GW: it is supposed to be runnable on demand. but also periodically.
LK: it can be periodic if they want also
SG: I think that's what amtu does
GW: do you list a sample cron job for it.
MA: I don't think amtu lists a sample cron entry
GW: want to make sure we don't have multiple instances running at same time
SG: I think there is a locking bug fix to make that work better, but I don't
think we are protected from database issues
GW: I have to make sure I don't run multiple instances ...
MA: there is a built in functionality for the pid files
GW: yeah, I can use that for sure. sounds like splitting it into 3 parts is
only workable solution. let me try that and I'll see
SG: I am confused. we were talking about running on demand and now the
init script
GW: I was thinking about using init script in cron job and was asking if
that is possible
DW: yes ..
SG: would it have to be turned on?
GW: you can run it at boot time.. it doesn't need to be proper init script
it just needs to be runnable by initscript
DW: we can write policy to have it runnable by sysadm, so it will have one
that is at ranges so it can transition to systemhigh
GW: ok, that sounds even better .. so probably not init script proper unless
somebody decides they want to run at boot time. I'll take what I have,
take out aide calls, make it separate test for high and low and that
should be the basis.. so we want to go down to other highlight on bug
list?
SG: yes.. there are a couple ...
GW: crontab man pages reference old environment variables. that's probably
low priority
SG: I need to have the repo take arbitrary packages ...
GW: 223532 ..
SG: looks like maintainer is looking for direction. I guess he assumes
upstream has it right. but it was pointed out upstream behavior is not
correct. he needs advice to see if that is what we need. I think last
person commented on the bug was klaus kiwi. It is the kind of thing that
if behavior is not correct, then a patch should be proposed.
GW: who makes that determination, a team of engineers at RH? what is the
process?
SG: not sure
GW: I think it is only a doc fix .. question is do you agree?
SG: I don't know I would be willing to bet no one notices ACL list unless
they use it. I am just saying that ...[phone problem started]
GW: let's talk about bug highlights quickly then before this noise gets
worse on the line
LK: I have one quick question. klaus there is still some policy for xinetd
in lspp policy module is that still needed?
KW: I need a test to see if it is. I have a another for lspp mode selection
..
LK: I am running without that policy module and not sure what problems I
should be looking for
KW: we shouldn't need the policy later I think
SG: there are 3 audit kernel bugs. I was talking with Al Viro this morning.
he was planning to send a backlog of audit patches to Linus tonight. Amy
submitted patches for those 3 bugzillas but I was not sure they are
ready for upstream. I'm wondering what the status is, is she happy with
them to be upstream
KL: she is not on, I'll ping here. I think she posted them as untested .. so
unless someone else tested them I think they may need work. I'll ask
her.
SG: I have not seen anyone complaints about that.
EP: I pulled them in and tested and they seem ok, but not quite right
SG: we have Al's attention to get patches in .21 kernel. I think there is a
2 week merge window
EP: yes it is.
LK: Eric, do you know of any issue with those patches, and does amy know
about them?
EP: yes and yes
GW: I didn't see anything obvious about console login .. I don't think you
did either Linda
LK: I couldn't see any debug output for init. I'll try to instrument an init
to see if it gets the getty and try that
GW: doesn't init have debug output already?
LK: I have not seen any. the inittab entry is put before first boot. we only
see this in lspp configuration
GW: created during first boot?
LK: yeah, if I look at it, it is there ..
GW: are you seeing the right file
LK: maybe I'm looking at wrong one
KW: ...
GW: I plan on reinstalling this week.
LK: I did a kickstart install using the version I modified to set CAPP or
lspp mode. The difference is that CAPP mode isn't setting policy and
polyinstantiation and in that case it worked. I got console login prompt
GW: but no Avc. well .. I plan to install and I guess I'll look at inittab
creation process
DW: use enable_audit.pp file to see if you get any AVC
GW: you have to load that with -b because it is a base module
LK: how do you do that?
GW: look in /usr/share/selinux for that file
DW: use semodule -b enable_audit.pp to see all the suppressed audit messages
SG: on irc we were talking on audit -f field not working correctly, so do we
want patch to fix that?
LK: we were on agreement that it is nice to have. so if you can backport
then it'll be good but we don't have a test case to test that.
GW: I think at some point we need to stop picking up packages unless it is
data corruption or big problems fix
GW: we were all in agreement that we like it fixed and we'll pick it up
KEW: I have no problem with fixes but new functions will break our tests
GW: yes, we need to start locking functionality
SG: this is not a functionality but rather a case statement missing which
caused problems
GW: this we would like to pick up but as we move forward we need to
scrutinize what we pick more
MA: 223894 bug, that seems to require a patch to introduce audit
functionality in cron.
LK: Dan did an update for that
SG: did you work on that one Dan?
DW: I'll check on cron maintainer and see if we have that fix in.
GS: so we should expect vixie cron package soon. Until repos are
restructured, I'll try to keep list with bugs and packages. we can use
that as basis for discussion
SG: when bugs change their status to modified that should be removed from
discussion, because that means it is fixed and on its way to QA
GW: unless it is not fixed or we see problems. we have to drive our bugs to
verification status.
SG: right, I'm saying that because there have been few people asking what
verified means
GW: right because they don't map one to one .. like when we close it or we
change severity, we have to put notes in bug and the mirroring process
is till being worked on on both sides ..
just FYI .. the annoying noise on the phone line was not coming from your line
Linda :)
Bugs / remaining tasks
======================
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
