10/09/2006 lspp Meeting Minutes:
===============================
Attendees
Lawrence Wilson (IBM) - LW
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
Steve Grubb (Red Hat) - SG
Eric Paris (Red Hat) - EP
Linda Knippers (HP) - LK
Matt Anderson (HP) - MA
Paul Moore (HP) - PM
Klaus Weidner (Atsec) - KW
Joe Nall - JN
Tentative Agenda:
Kernel / Rawhide update
-----------------------
GW: how is it going with Eric's kernel. I presume everyone is testing .51
kernel
EP: I decided today looking at the patches that all of the secid
reconciliation stuff will not get pulled to beta2. The patches I have
now are the CIPSO patches and the IPSec leak fix. The deadline is today
and all the secid reconciliation patches are not ready, so they won't
make it. We are also still missing audit of security changes for IPSec
labeling. So kernel .51 has more than what GA will have. The auditing
for IPSec can still go in after beta 2, but secid reconciliation
patches are too big and touch alot of things for me to be comfortable
and sign off on them to put in.
KW: what's the fix if we don't have those patches in?
EP: Basically like we were before, everyone patches and does it their own
way. This was mostly when Dan wanted this feature for customers to be
able to map labels. I am not very familiar with LSPP requirements, but I
am guessing you are still able to label IPSec sockets. As far as the
cipso stuff, it is pretty much complete.
KW: lspp requirements are not specific; have MLS to use with labeled
networking then you can turn off unlabeled. Admins can choose cipso or
ipsec but not necessarily we need to have both.
EP: I tknow that cipso is great. the only issues are the reconciliation
stuff, IPsec still has issues, and has at least a couple of weeks worth
of work. Maybe IPsec stuff as it stands is adequate for lssp, but for
general commercial customers it is not as usable.
GW: if there are bug fixes, can those still be made?
EP: yes, if MLS contraints are not being enforced somewhere then we can fix
that
GW: the ipv6 is a government mandate ...
EP : I can push another kernel, get that out in a couple of days so you can
see if it has everything needed for lspp.
KW: I remember when I looked at cipso, it is a simple solution but it was
doing what it needs to do for the job, it has a problem with not
encrypting data but that is an implementation issue.
EP: we don't see cipso as a long standing solution, but we took it because
of its MLS capabilities.
KW: only issue with cipso is the different mls constraints but that can be
fixed in policy
LK: does that mean compat-net is on also, not that we don't have the id
reconciliation patches?
EP: no, this is a separate issue. I don't want to have compat-net on, but it
can be enabled if needed.
EP: James and I want the IPsec discussion to continue and quickly, but
getting it in rhel5 GA is not gonna happen probably.
GW: that's unfortunate from a usability standpoint, but it is good to at
least get bug fixes in. As soon as we get that kernel with what actually
made it in, it'll be very helpful to make sure it meets our claims
KW: also with that, what userspace tools and versions we need. preferably
something from an rpm rather than something that needs to be patched
EP: as far as policy we will ship with default policy
LK: is there userpsace netlabel tools in?
SG: not sure.
PM: Sorry I missed part of the beginning, but there is also going to be
small policy changes for netlabel even if secid patches won't go on; we
need further testing with policy. Now that things are slowing down with
kernel, I'll spend more time on the netlabel tools
GW: how long do we have to get bug fixes in?
EP: I don't know the date exactly.
SG: if it is a real bug we can fix it, we are not even in rc1 yet. However,
by the time we get to rc1 it will be hard to get things in unless it is
a security hole or escalated privilege issue
GW: so we need to make sure our network solution is working soon
SG: if we need to carry a certification kernel, we can do that, we just need
to know early
GW: not as a good of story, but it's good to know that the option is there
SG: yeah, we need to get stuff in by rc1. Eric, when can you get a kernel
out?
EP: I can have a build tonight, however since the cut off date is today,
lots of things might make it into the tree last minute, so it's better
to wait until tomorrow for a more official build, so sometime tomorrow.
GW: sounds resonable to me, thanks
PM: Steve if new kernel doens't come from you, can you make them available
to us somehow
SG: yes, that's what we are doing. I was on vacation last week otherwise the
last kernel would have been an lspp kernel
EP: it'll go out through steve most likely.
GW: thanks for tryig to get everything in, I know it is difficult. We'll
work on getting some testing as soon as we get the kernel.
SELinux base update
-------------------
GW: Dan is in New Orleans, I don't have any issues with policy, anyone has
something to bring up?
KW: I have a fairly big issue regarding how the entire chain is supposed to
work, if you log in through ssh and how everything is labeled correctly.
I think we still have some issues with that. one issue is that mls
restriction are not correclty applied on PTYs. also ssh has the
overrides that can override them even if you get the labeling on pty
correctly.
GW: what happens if that user newroles after they ssh in also?
KW: Earlier I made a proposal to not allow regular users from using newrole.
I know it is ugly but it is the only solution that I see that doesn't
have security holes. does anyone have a solution that they have tested
and are confident in. I think I'll try to do a more detailed write up.
do we want this on selinux or lspp list?
GW: probably both lists
KW: it's unfortunate, but I don't see another possibility other than
restricting some operations. The suggestion about putting TE rules to
restrict access to PTYs, I am not confident that is secure and works
GW: and with that we would have to test TE as well.. so what is the
plausibility to restrict new role?
KW: regular users need to be configured to the right context when they log
in. In the future we can use extentions to get to the right level. Mike
thompson has been putting work in newrole to get it to work with
polyinstantiation, but it seems hard to get it working correclty. We
might work on that later, but for now we can just say it is not
supported; so newrole can't run with polyinstantiation since it needs
suid. Does any one have requirements that something breaks if newrole
can't be run by regular user, or that they expect polyinstaniation to
work with newerole?
GW: this will be only on evaluated configurations?
KW: yes, my suggestion is to restrict newrole for evaluated configuration.
if not running evaluated configuration then you are not affected with
this.
GW: do we need to have more discussion?
SG: yes, I think so, we need to understand this more
KW: I will create a wirte up for that. We might need a patch for .... hope
we still have time for that kind of patch
SG: yes we do
GW: also, this is targeted to server market, so we don't expect regular user
to log in anyway.
KW: this mainly affects log in from console. A side effect is that we
wouldn't care for PTY enforcement since we would take care and restrict
all the untrusted applications that can do that
GW: it would simplify alot of the certification work
SG: I think we also have bugzilla open for that (200110). We need to put
something there once we decide what to do.
KW: If there is consensus or solution, then I'll update bug
EP: I'll watch the mailing list, and I can update the bug if you get a
discussion started
KW: ok, thanks
GW: it is a big change to the model, but it is a simplification, so let's
think about it quickly and decide.
KW: I can be convinced about other solutions too, but it seems there are no
other solutions that people are confident with
GW: yes, and I don't think we have an end to end solution that people have
tested in order to come up with issues and other alternatives for it. I
know this is not a happy thing, but it might simplify things for
certification
MLS policy issues
------------------
Newrole & VFS polyinstantiation
---------------------
PTY enforcement
----------------
Audit userspace
---------------
GW: Anything Steve for audit userspace
SG: nothing
Print
------
GW: Matt, are there any print updates
MA: I got out an updated patch to Tim last week, it was included in cups
1.2.4-8 that went to rawhide late last week. I've had only couple of
minor coding updates since then, all work has been policy related. The
main hangup is the cups socket which is created in SystemHigh. I am
trying to get that created in systemLow now, and put the right mls
levels so that user programs can write below their level
KW: you can also make it a trusted object.
MA: Make what a trusted object?
KW: make the socket a trusted object. It might help to give multiple
elevated priviliges to multiple applications. Look at how /dev/null and
/dev/zero are handeled in the policy, those are trusted objects.
MA: great, this just might be the clue that I needed; I'll look at that. I
also need to clean up a patch and I'll send to the list
CIPSO
------
GW: anyhting you want to tell about cipso Paul
PM: It probably need some policy work, I started working on that this
afternnon, once I get rhel5 kerenl, I'll finish up work on that. so I'd
expect something by end of week if not sooner. I'll push out patches on
list and get things into reference policy. Chris BePinito was creating a
policy branch, so that will go in his branch, and then we need Dan maybe
to take those changes in. As for the netlabel tools there was talk to
get changes of configuration file to run it. I haven't had time to work
on that; if anyone wants to do some testing, that'd great. if you need
help setting things up, let me know
SG: you said you don't have a copy of the init script that you are using now
PM: no, I directed all my attention to kernel lately. If you want a
configuration, can you slip the dealine for me to add a configuration
file.
SG: I can't do that. Paul, myabe see how audit does that using configuration
files
PM: I want to use a slightly differnt approach than what audit uses. is
there a date for userspace freeze
SG: maybe Friday
PM: I am thinking between policy fixes and user space tool, policy should
get preference, is that the right way of looking at it?
SG: yes. policy need to be fixed
LK: is it useful to get a configuration file version that can be later bug
fixed than having something that comes in new
PM: sure, if that is how we want to do that, I can have a config file for
now.
JN: Have you tried using a script that reads a config file?
SG: that's what the audit system does
JN: use scripts basically
PM: that was my initial argument but steve didn't likt that. I can give you
a configuration file today if that is what you want.
JN: I am just doing this from memory, for iptables, you have a file and
there is a script that goes and reads that file.
SG: that is what I was thinking, something like that is good to do, it's a
matter of coming up with file name and syntax. we really want netlabel
usertools to ship with a config file and init scripts.
PM: well, an approach like that works for iptables and audit. but with
netlabel there are lots of parts that make a netlabel. there are
multiple configs and you can't specify them all on same command line
LK: but can't you still do it with a script, just have it in the right
sequence
PM: why can't we just have a simpele script file
SG: we can, but we need it shipped with userspace package, so that when they
do rpm -ivh it will get labeled correctly
PM: ok, that depends on how you build the rpm I think
KW: and we need to make sure it executes in the right mode in enforcing
PM: sounds like policy fix
LK: is the script going to be writable?
KW: as long as it is writable by admins, it's not a problem.
SG: I am suggesting making a config file that init script can parse through
and issue commands
LK: so init script will execute.
SG: yes, so it fits with sysconfig system, and we can have a config file
that has parameters that will be executed and issue the right commands
PM: ok, I'll make that for you in a minute. seems to me that it is how you
build the rpm
SG: you have a test setup of how to test
LK: I usually follow the README
PM: If you have problems Steve, let me know, the README has step by step
instructions
IPsec
------
GW: doesn't seem there is anyone working on ipsec on the call
JN: I have this question. whan I asked this earlier I was told that the
length .... venkat said that labeling of ip sockets on local host came
from the secid reconciliation patch. so now that we don't have that,
are we not going to have support for the labeling.
GW: that would be a bug I would think
PM: from a netlabel point of view there is no differnce between local host
and remote host. for IP I think it is related to how xfrm is setup
EP: you are correct. TE and those things are not going to be in rhel5 as it
stands. so local host is exactly the same as remote connections
JN: but if I have ipsec netlabel for remote connection, I can get that info
KW: also important that mls connections are correct on local host
EP: ok, I'll try to spend time tomorrow to see what it would take to bring
those patches in
JN: I have been watching the schedule, and I knew it was going to break just
didn't know where. WE need to get correct MLS context from local host as
well. the id reconcilliaton is not a big deal, but it is a consistency
issue
EP: please put that on list, and I'll make sure I and venkat respond
JN: One more question, are we gonna have 1024 or 256 bits policy
GW: yes, it has been already setup to 1024.
KW: it is a configurable option
GW: I needed to update the rawhide policy for the milestone 4 in order to
make it boot. it is also documented in the bug (issue tracker# 103513)
about the boot failure. if you are having problems, use the rawhide
policy and see if it works for you.
GW: let's get that discussion on list. that's the problem with including the
features in bug fixes.
ipsec-tools: racoon
---------------------
GW: as far as I know racoon patches are fine
xinetd
-------
SG: any xinetd news?
SG: there is an open bugzilla on it, about some label association problem
that Linda opened last week.
LK: I opened it from info on the list, just to keep it documented. I'm not
an expert on it. But I want to say it was an issue with it having the
rightlevel, but the wrong type
GW: was this related to reconciliation or unrelated
LK: I believe it was unrelated. Am I describing this correctly Steve?
SG: when it starts up ftp it needs to be in ftp domain, and we are not sure
if xinetd needs to do the labeling or if it needs to do some
transitions. The solution seems to be a policy change, otherwise I'd
have to be hard coding policy in the daemon. The other option is to have
a config file with policy in it
GW: I don't think you need a config policy, Smalley won't like that either.
SG: we'll work through that later this week
GW: ok, so we'll discuss that more on the list
Single-user mode
-----------------
GW: I haven't played with this yet. I believe it is in already
Self tests
-----------
GW: I worked on that this weekend
SG: if you have fedora extra repository, you need to install the aide
package to get that on your system if you like
KW: have you seen Linda's comments about ....
GW: if I can make that cleaner that would be desirable
SG: I figured after config script is run, it would go and get a snapshot and
record all the changes you made
GW: I've been keeping track of that, obviously I can't query rpm.
SG: we have plans to tie aide with audit system
LK: right now, using kickstart (KS) script you do have an idea of what files
got modified
GW: I'll try to use that
KW: it is not helpful for suid bits, since it lists files that didn't get
suid bit
Cron, tmpwatch, mail, etc.
---------------------------
GW: is cron fixed? have people been running it on mls systems? that would be
something good to test that. I also want to test it with wrapper program
to mail the admin.
Bugs / remaining tasks
----------------------
GW: we are all hopefully writing bugs. We don't have a crisp definition for
the cutoff date
SG: either going to be this Friday or next Friday.
GW: I think after freeze we need to consider including things in KS
LK: I have a question about ks script. What about the fixes we need in,
anyone interested in accepting patches?
KW: I can maybe replace it with a git archive so that will be easier.
LK: I used it and the system didn't boot due to some storage issue. I know
it used to work, so I am trying to figure out what changed and I'll send
patches
LK: yes, I can help with that, and patches are very much appreciated
especially with things like print from people who know how to set that
up.
KW: do we want to keep it ad hoc or have a git tree
LK: well, I've been wanting an excuse to learn git
MA: I personaly like cogito, it has an interface similar to cvs and svn.
KW: well cogito ties in into git as well.
Final cutoff date
------------------
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
