Disclaimer: This call was very hard to follow. There was a lot of people and a
lot of discussion going on. I types as fast as I could and tried to follow it as
best I can. So feel free to correct me if I captured something wrong.
10/16/2006 lspp Meeting Minutes:
===============================
Attendees
Lawrence Wilson (IBM) - LW
Robin Redden (IBM) - RR
George Wilson (IBM) - GW
Joy Latten (IBM) - JL
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
Linda Knippers (HP) - LK
Lisa Smith (HP) - LMS
Matt Anderson (HP) - MA
Paul Moore (HP) - PM
Klaus Weidner (Atsec) - KW
Darrel Goeddel (TCS) - DG
Chad Hanson (TCS) - CH
Joe Nall - JN
Bill O'Donnel - BO
Tentative Agenda:
Kernel update
-------------
GW: I hope everyone is running lspp.52 kernel to make sure it is stable. Al
anything we need to know about the kernel
AV: nothing going on with respect to mainline.
GW: Al was saying that there is nothing going on with kernel. At some point
klaus was talking about not being able to boot with current beta, but I
got that working fine on ppc. Anyone having any issues with it?
SG: no one responded on the list saying they have problems
GW: no news is good news. I assume people are having good luck in that case.
Anyone wants to bring up any other issues about the latest beta and
kernel combination?
Beta / Rawhide
--------------
SELinux base update
-------------------
GW: Anything about selinux
MA: There were some netlabel policy changes that I pulled last week, I filed
a bugzilla but didn't see anything, is that going in rhel.
SG: I'll check on that
IB: did you file against fedora
MA: against beta
IB: is that 210426?
[ we dropped off for a few minutes ]
MLS policy issues
------------------
Newrole & VFS polyinstantiation
---------------------
GW: As for restricting newrole to admins, there are different mechanism
that can be put in for that. For server market, Casey pointed out that
these can be large machines with people logging in. What is the
possibility of restricting newrole?
JN: for (CMW?) that I had most access to, if you do set levels which is
equivalent to newrole it just worked. We routinely log in to machines
remotely then change them, there has to be a way to log in to box and
change.
GW: we are talking about restricting it only to admins
JN: we seem to have more root level applications. A lot of applications need
to be root; we will end up with admins ending up with privileges more
than what they already have
GW: which is not desirable
JN: in CMW model there is a privilege to write the audit.
SG: your applications need to start as root then drop privileges.
JN: we just have not gotten to that point of work.
SG: dbus and name service caching daemon has a patch that shows how to drop
privileges.
GW: Newrole is scary for everyone. Mike Thompson has been working on it,
Mike any updates?
MT: the work I did I sent out to the list and only stepehen smalley had
minor comments, mostly my use of a naming scheme. If anyone has
suggestion on how to proceed from here, that would be appreciated. Has
anyone looked at the patches, I know they are big, that's because they
do a lot of cleanup since newrole was not suid originally. Did people
look at the format? At this point basically the state they are in, I'm
confident and since smalley didn't have much to say, I hope they are
looking good. I use it on my system and it works. I'll clean up patches
and send them out later today.
GW: would the idea be it is always setuid, or just for evaluation
configuration?
MT: one of request that dan and RH gave me is to be able to build single
binary to use on systems that do not need newrole to be suid. and have
that binary retain those abilities and function to do auditing and
namespaces. I don't think we found a good solution for that. I was
looking to have a single binary to be suid or not. Steve suggested if
you make it non suid, then you check for capability to audit. if you are
not root, then you don't bother with auditing and namespace, but if you
are root, you would do that. that's the state of things. It is capable
of doing what RH wants, doing namespace and auditing. In no suid
scenario root is audited, and everyone isn't. if that's not an issue,
then we can go ahead with that solution. one solution Russel Cooker had
is to break newrole in two packages so you can install it on systems
that need it. You wouldn't have this extra root hole lying around. I
like that solution, but it is not my choice
GW: if we were to incorporate in TOE it would be suid
MT: it doesn't have to be suid if you restrict to admins only, but if you
want it open to all, then it has to be suid
GW: we will make it more dangerous for the evaluation
MT: you will be adding another suid, so if you consider that dangerous then
yes.
GW: that code would need to be analyzed very carefully.
MT: yes, and I have not seen people looking at it and scrutinizing it as it
needs to be.
GW: ok, thanks for the update, put it out again and let people look at it
and see if they have anything to say. still doesn't answer the question
if we want it in evaluation. Joe you said there are other systems that
don't pay attention to pty
JN: yes, but the CMW is not lspp evaluated
GW: there is the idea that when you newrole the two ends of pty can become
at different levels and you can potentially downgrade info on that
channel
BO: I would have to check
GW: it does look like an obvious route to downgrade. It would solve that to
remove ordinary users' access to newrole. I don't get the sense if folks
want that or not. also what does it mean to do newrole over a ssh
connection. this is a ptty console scenario rather than a network
scenario. I guess this deserves more thought. Since I am not hearing
more voices, we need to have more discussion on the list. We don't have
good solution for the pty disclosure route right now. We'll try to get
more discussion on list and mike will post the new versions of newrole.
The other issue is how much time we have to put changes in user space.
Acceptance for Mike's patch need to happen quickly
PTY leakage
------------
Audit userspace
---------------
GW: Steve, anything new for audit
SG: no, been really busy with other pieces
Print
------
GW: Matt, any update on print?
MA: I got two minor feedbacks based on the patch I posted to lspp list the
other day, one about the level of messages should be switched, the other
is to change the access decision type of the generic file. I made the
changes and sent it out again. It looks like printing is working, we
need some mls changes that make range printing work. Please test it, and
let me know of any problems so changes get aback to RH in time
CIPSO
------
IPsec
------
Labeled networking stabilization
--------------------------------
GW: Ok, for networking, what exactly do we have and if that is sufficient, I
am not clear on that. The work is continuing to do the reconciliation
patches, and there was talk about having a run at that. That is causing
me some worries about the stability and the final outcome in terms of
features. Joy, also Paul had an ipsec question.
PM: I had a quick question. can I use ESP or AH for labeled IPSEc
JL: you can use either one
PM: what would happen if I use both
JL: I recommend you use ESP with authentication, but you can use both.
PM: my question is not generic ipsec, it has to do with labeled ipsec. if I
use both, do both SA get labeled with context
JL: I don't think it should matter. you'll have policy that specifies ESP
and AH, I wanna say you will have one SA
PM: It will create two SAs
JL: ok, I'll try it and see and send an emailabout it
PM: I wanted to see how it will resolve the multiple context.
JL: yeah, I'll try that
GW: any specific cipso or ipsec issues?
JL: I do have a labeled ipsec issue. I brought this up on the mailing list,
but no one responded. I was playing with labeled ipsec, now I don't
understand how mls context is used, but I noticed that no matter what
mls sensitivity I had in policy, SAs were always created with generic
label. I am concerned, because I though that we wanted to use MLS to
create fine grained sensitivity levels. I wanted to bring that up, I am
unsure what the design should be. No one is responding on the list and I
don't think it is creating MLS portion of SA correctly, but it seems to
be doing the TE part correctly. I think we care most about MLS though
GW: I agree, what is it doing Joy?
JL: It seems that it is taking the flow SID MLS level. I can't find were the
level of flow SID is getting generated, and I can't see where that is
coming from. I don't know how to fix that because I don't know what the
design should be. all I know is that SAs are not getting right MLS
level. where do they get it from?
DG: I'll email venkat about that. I'll have venkat look at that
SG: well, one thing, we should log that in bugzilla so we don't forget it.
GW: if you do that that would be appreciated Joy
JL: ok, that's the only issue I had.
GW: we care about that, so glad you brought that up. let's get to bigger
question now. Is there plan to pick up the ongoing work, I mean secid
reconciliation patches
SG: we are waiting to see where this goes. if it gets working soon, next
week or two, we might pick it up, but if it drags later that'll be bad.
since GA kernel will not match what we have in 5.1. We need to see if we
can pick it up. no guarantee that we pick it up, but we have strong
reason to do that.
PM: It seems like james morris is not a big fan of overloading secmark, but
seems that venkat believes in that. if we need to get that in the
future, we need to get away from overloading the secmark field
CH: we would like that, but we need to get another field, and we can't
PM: but I really don't think we will get another field. one thing we need to
deal with is forwarded traffic, other thing is local host. to deal with
forward traffic case, we have flow in and flow out. netfiler has the
forward hook that ties it to, would that work?
CH: the idea is we have an ipsec label that comes in that needs to be
checked.
PM: kind of what I was afraid you'll say. It is being consumed by machine
and relabeled. the unfortunate part is that I don't see it happening
with overloading the secmark
CH: problem is see to if there is anything else we can use. not sure there
is anything else we can use. we have multiple label sources
PM: one thing to remember is that's the only field we have in the skbuff.
CH: bigger problem we don't know when to use something or not. If we can
make logical deduction, then we can get around some of this as well.
PM: The problem is that you are passing this up into user space
CH: it is transient through the machine
PM: if it is not going to user space, assuming your policy doesn't change
and you have static routing tables, you can say before hand the flow of
packet.
SG: assuming and relying on routing tables. if routing info gets messed up
you have to make sure that packets are not routed incorrectly
PM: I assume static routes are considerd trusted DB
CH: doesn't really matter.
DG: everything is labeled
PM: if you are not sending out on ipsec tunnel then the label isn't
preserved
SG: anything going on on e4 are top secret and anything coming in on e2 is
not.
PM: if we have static routing, and trust admin will do the right thing, so
they only do good routes
CH: it is not subverting the security mechanism in place, there is no
security mechanism.
GW: and we would have to document that Paul
PM: this is just normal routing, normal ip
GW: but we don't normally make claims about firewall
PM: this is routing, not firewall.. not saying it is the best solution but
we need solution at this point. I just think we need to come up with a
solution. I think the secid work is couple of different things; it is
introducing flow control that was not there before. then there is
secmark field and the skbuff struct. it also tries to resolve labels
down into one 32-bit value. That is 3 potential labels that are getting
resolved to one. issue is that how you resolve external/internal lable.
That is causing pain. I tend to think the best way is to give up on
reconciliation aspect and focus on flow control
JN: I think there only should be one label
CH: in general if there is something on interface, the problem is you'll
always get a secmark label. in theory you'll just use most descriptive
label. that would be label of secmark
PM: I think it complicates it a bit. cipso is not best example, this is not
problem with cipso. you do have to parse, but there is cache in cipso
code to make resolution pretty quick.
CH: we have same thing with ipsec because we have that pointer, but it is
not always there
PM: if we can soleve that, it'll be much better
DG: I'll be happy to see that as well
CH: there are limitations due to current framework
PM: if we do flow control without reconciliation , it'll be a lot easier
GW: this sounds like we reached a kind of resolution. maybe we'll add in an
integer.
PM: another integer will not be added
GW: sounds like you'll have full reconciliations
PM: james morris doesn't like that idea
GW: are we going to make progress on this. neither solutions is possible
PM: I think it is hard from technial point. I am not confident the work on
it will be done in the next week or two
GW: can james budge
PM: I doubt that. Secmark is out there, it is user visible, changing it will
break stuff.
GW: well, but it has not been out very long, so better to break it now than
later
PM: I have feeling the kernel guys will say it is better not to break it at
all.
GW: sounds like this discussion will go on, and someone needs to compromise.
Will it happen in a week or two?
SG: we'll have to see where things go with this.
GW: ok, thanks for this discussion. it's a bit clearer to me. we'll talk
more about that, but doesn't seem hopefull we'll have a full solution.
CH: if you don't have one consistent model, there are lots of edges to test.
I am afraid later we'll find edges that we missed.
GW: we're gonna need to simplify for the evaluated configuration at some
point. if we can't come up with solution for newrole and pty, then we
have to restrict newrole. if network reconciliation will not go in,
then maybe we'll have to look at the compatibility flag. we need to have
a solution eventually. At least we have cipso there, but no future
looking solution.
PM: trusted solaris has something called cipso for ipv6, but there are no
documents out about that. I'll look into it.
GW: yes and DoD will request moving to ipv6, and we don't have that solution
PM: we should potentially implement cipso to handle category issues. we have
the kernel freeze, so I don't know the feasibility of that
CH: is this your idea of having different DOIs.
PM: cipso implementation right now uses tag number one. there are tags which
use range, or list categories. those are some limitations of the ip
headers.
CH: can you enumerate them and have each categories on?
PM: all comes down to what you set in your header. if you go with enumerated
one, it's a 16-bit field. The way I plan to implement this is to specify
list of tags for each DOI. you try to fit in number 1 tag, if not try
the enumerated tag, then range tag, if that doesn't work, then you fail
it. it might not work in every combinations ofcourse.
GW: we'll see what happens, but sure it'll be nice to have a complete
solution. Steve, I hope you are right and it can be resolved in the next
couple of weeks.
xinetd
-------
SG: one open bug and didn't get to look at it
Single-user mode
-----------------
GW: haven't tested it. I'll drop this from the agenda
Self tests
-----------
GW: I installed aide on my machine.
SG: we have new package, with fixes and interfaced with audit system and
works with extended attributes
GW: should I pull from fedora extras?
GS: no, right now it is off james antel people page ../jantel/aide
(aide-0.12-1.src.rpm). it should run along side iptables. I think we got
it running after iptables
GW: Ok, I also pulled iptables from your repo. Networking is still the big
issue and we need to test with the .52 kernel and other kernels when
they come out. Any other issues? Ok, We'll adjourn the 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
