01/15/2007 lspp Meeting Minutes:
===============================
Attendees
George Wilson (IBM) - GW
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
Klaus Kiwi (IBM) - KK
Irina Boverman (Red Hat) - IB
Steve Grubb (Red Hat) - SG
Dan Walsh (Red Hat) - DW
Eric Paris (Red Hat) - EP
Klaus Weidner (Atsec) - KW
Chad Hanson (TCS) - CH
Ted Toth - TT
Tentative Agenda:
Kernel / Beta / rawhide update
===============================
GW: how is the current installation 01/05? I had an issue where I can't
build policy modules
DW: update to latest policy and should will fix it.
GW: ok, that's great
DW: I put the updated policy .27 on people page
GW: thanks. I'm hacking on the self tests policy, and was trying to get
audit to build modules correctly. Ok, so we need lspp.62 and policy
package, anything else?
SG: openssh I think also
GW: that will pick up extended syntax
SG: yes. I need to make scripts to pick up the updated packages to put in
the repository. so I'll work on pulling the packages.
DW: openssh.16 is up on people page. and klaus weidner put some notes and he
tested it out.
GW: great because we need that for the test cases.
DW: scp works with that one as well.
KW: you can use that if you are using labeled networking. Not sure what is
happening but I was able to use that to select a level even not using
the right xinetd. That is a security hole
GW: that is a manual fix right?
KW: yes, there is no way to do that with config
GW: we'll document that very well then
DW: it wouldn't know you are coming out of labeled network. that's the
problem
KW: yes. I think we need an xinetd patch to fix that. The problem is that it
tries to get entire context and then gets confused. One thing that would help
is changing default level for normal users to be classified other
than systemlow
GW: what would that default level be?
KW: if people configure users to get an s1 level then this might go away
DW: I have a feeling this can cause lots of problems
KW: it needs testing
GW: what if you can configure labels in xinetd config file, it still sounds
dangerous
KW: not sure if it is desirable, since you don't want to force everyone to
use it. I think documentations solution is a good solution. unless we
want to change that in xinetd.
GW: kinda unpleasant to have to manually configure this
SG: I don't think we have a problem to put patch in but it's getting late
kinda. if we have to we will. I don't think there will be problem with
xientd using a label. I think we need to create another parser for that
which has to verify when daemon starts.
GW: sounds like you need context string
SG: per service or default?
GW: sounds like per service and use it for ssh now
KW: there is a config file for services anyways where you can put an option.
you can add to that
SG: it will be a separate configuration line. I think there are lots of
people that prefer xientd take that from policy rather something admins
configures
KW: not sure policy is the appropriate place. in a sense it is something per
service.
SG: is this problem because get getcon is not working right
KW: I didn't check where exactly it goes wrong, but now it is a problem when
using the label flag
SG: wondering if third parties expect getcon to function.
KW: I think in a way that should be decided for admin. pretending something
is coming at a certain level would be unsafe
SG: I wonder if there is libselinux lib call to use. somehow I want to think
it wants to be controlled by policy so people can do information flow
analysis. if you take it out of policy then there won't be one file
people can use for information flow analysis.
KW: not sure this is a policy issue, there is no info to base policy
decision on. also applications must differentiate between the labels. if
getcon returns label, and if it had no info, it would be wrong thing to
do
DW: getfilecon is an example. I take it back, I think it returns nothing.
SG: Wasn't there a requirement where admin has to do auditable config change
to allow imports or exports
GW: yeah that is a requirement. you wouldn't be auditing at that level of
granularity but you would be still auditing
SG: we were counting on changecon to do that.
GW: requirement is that it is auditable
KW: if it is a known routine, it doesn't' need to be auditable if it only
happens once
SG: wondering if we make a change in xinetd it sounds it falls in the
import/export section
GW: it still follows requirement. just not with granularity
SG: there is no program to configure xinetd
GW: but you can place watch on the file .. right?
SG: but in the past, placing a watch is not sufficient. since you can't know
what the change is
GW: good point
SG: I'll think about what we can do. if xinetd needs to do something when it
starts up. It may be easiest thing to do, is to have default
configurations
GW: sounds like safe way to do it.
SELinux base and MLS policy update
==================================
LSPP ks / config script
=======================
PAM and VFS polyinstantiation
==============================
ssh level selection / multiple instances
========================================
IPsec localhost, IPv6, 1st packet drop
======================================
GW: we were talking about current installation. we'll talk about networking.
joy can you give us status please with respect to ipv6
JL: everything should be working ok with the patch I sent. with patch, now I
can do regular ipsec with lspp kernel. so it seems it cleared a problem.
with lspp.62 and the patch I am able t do regular ipsec. I am having
problems with config file for racoon. once I'm done I'll run more stress
tests and verify all is good. that's about it. if all goes well then
only issue is the loopback with labeled ipsec. i was looking at racoon
to see if there is an easy fix. I'll look at that next
GW: so ipv6 change is hopefully last kernel change
JL: I made change for labeled packets that affected flow cash and that
affected regular ipsec. I am only having problems with racoon. As soon
as I have that right I'll run more
GW: when do you think you will have results?
JL: I am working on it now
EP: it seems I've managed to get every patch for lspp in except for the one
you just talked abut
JL: I'll put the patch in bug report
EP: I already got it and building lspp.63 with it now. it seems we have
everything in GA and carrying one small patch
GW: hope that is the case.
EP: I thought we had alot to carry, but Friday we agreed to take in the lspp
fixes
GW: userspace is locking down too, just not sure when.
IB: it is today
GW: from what I can gather policy is a bit more flexible. There is an
interesting property of linux ipsec that came up when Ted and Joe were
visiting; apparently when you have negotiated connection, the first
packet gets dropped. most people don't care, but I was just hopping
everyone is aware of this. since we are negotiating lots of connections,
customers might see this as non desirable especially BSD ipsec doesn't
do this
SG: is it tcp or udp packet?
JL: does this regardless of packet type
KW: what happens it returns "temporarily unavailable". it is better if it
drops the packet rather than returning error
SG: I think you are saying you do want to fix this
GW: yes, I think it will be desirable to fix it.
SG: we need a bugzilla
GW: I asked joy to open one but wanted to get your read on it
SG: I don't think it is desirable to return an error. so maybe it is a flag
that can be set to not let it do that. Either way, first step is to open
a bugzilla so that people can evaluate it. also a test case on how to
setup and maybe strace output if needed.
GW: can you provide that joy
JL: yes
SG: if you can do it simply that would be better that the lspp setup we
currently have
GW: thanks steve. I wasn't even aware of this property. it will affect
customers in this environment.
Self tests / aide
=================
GW: I was hacking on self test policy. As for cron not sure if anyone tried
it with admin mail. last word from camillo is that it is working
correctly. looks like we are down to wire. Irena anything you need to
mention?
IB: nothing
KW: Sorry I dropped earlier. I wanted to revisit the xinetd issue. I think
best in this case is to keep current setup and just document. I don't
see urgent need to modify xinetd or sshd
SG: maybe they can set up another alias address and that way they can come
in through a different xinetd. since xinetd can have 2 ssh running. we
can properly setup 2 configs one with labels and one without and have an
alias address
KW: it might be good idea to encourage admins to not use systemlow for
regular users. and that might fix things even. ofcourse it might break
things also but hopefully that is easily fixable
GW: so systemlow is special and everyone dominates it
KW: yeah I think that would be safer
GW: I see that as less risk
KW: we don't need to require that, but leave it as an option
GW: I would like to get Linda's opinion on that as well
SG: hopefully she can reply to the notes
DW: there is the new policy that fixes the ssh issue. all those should now
work. and seems policy is almost completed
GW: one other issue. when using the kickstart script, it relabels and then
init panics. it used to work, but I'll try with new policy and see if it
works. we don't want to have to reboot in enforcing=0 on first boot all
the time
KW: mls policy manually kicks off relabeling so things get relabeled on next
boot. but that sometimes doesn't work and kernel panics. it is supposed
to relabel things before it reboots but doesn't always happen?
DW: so you have the label file in the kickstart? do you have the -f flag
KW: doesn't have the -f
DW: you should probably have that ..
KW: it has a touch autorelabel since the config file doesn't work
DW: don't think you need the second touch since it does label twice
KW: works for some people but not others, so I need to look into it
DW: only reason to do touch again is if there are processes running that are
still creating files
KW: hmm it does a mount, so might be the problem since mount points don't
match.
SW: autorelabel does mount -a before it relabels.
KW: they are all mounted in accessible place for root
DW: if those paths are ... that can cause a problem
GW: can't we get it from /proc/mount
KW: it is wrong at that point ..
DW: with fixfiles, it get mount table and walks down file system and
relabels.
KW: maybe in this case it is better to do it with fixfiles
DW: we should figure out a way to not have to run autorelabel again
GW: any other issues. .. Klaus, I think linda was talking to you about few
issues ..
KW: yes, some policy changes for xinetd
DW: yes, I grapped those from you and put in .27 policy
KW: what's the status of your policy patches for ipsec Joy? and the patches
I sent you regarding the cipso rules?
JL: cipso also had some policy changes ... I can ping chris, but not sure if
he had chance to look at them.
DW: that's upstream, but do we have them in rhel policy?
JL: I was looking at pauls work and would've like to have had time to create
patch that merged our work. see if we can make it smaller.
DW: try out the latest policy and get to me right away and we'll get the
fixes in
GW: anything else?
KW: is there going to be another public beta before GA. I think last public
beta had problems
DW: I think there will be snapshot7
SG: I think 7 was snapped last week and should be coming up soon.
KW: one thing useful is to make those public since alot of people don't
have access to snapshot
IB: not sure if it'll be public. it'll be on our partner site and also i
think it will be on rhn on the beta channel. I can ask product manager
to let you know
SG: there is probably not alot we can do. there are many other groups with
their own thing that are part of this release. getting a public release
for lspp project only is not very likely.
GW: I think it's good to get feedback
KW: I think there were issue with beta 2; people who need access to snapshot
should talk to right people in RH to get that.
SG: for people doing development, I think there is a development program
that they can get software releases through as well. There's not alot we
can do to make it public.
GW: we suggested for interested people to join developer or partner program
with you
SG: I think everything we have is going into fedora
EP: alot of kernel work is going to fedora through upstream
SG: we have the kernel public .. so I think they can use that with a fedora
core
6 system. I wanna think we are not hiding anything
GW: that's not the case at all. only some people were asking how they can
get betas and we told them they need to talk to RH for that. do you know
what the overhead to join one of those partner programs is?
SG: no, but I know who to talk to. so if you have names, email me and I'll
be glad to help
GW: thanks Steve. Any other issues? ok, we'll adjourn.
Cron
====
Bugs / remaining tasks
======================
Final cutoff date
==================
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
