[redhat-lspp] LSPP Development Telecon 10/23/2006 Minutes
Loulwa Salem
loulwas at us.ibm.com
Tue Oct 24 02:20:40 UTC 2006
10/23/2006 lspp Meeting Minutes:
===============================
Attendees
Lawrence Wilson (IBM) - LW
George Wilson (IBM) - GW
Loulwa Salem (IBM) - LS
Michael Thompson (IBM) - MT
Joy Latten (IBM) - JL
Irina Boverman (Red Hat) - IB
Steve Grubb (Red Hat) - SG
Dan Walsh (Red Hat) - DW
James Antel (Red Hat) - JA
Lisa Smith (HP) - LMS
Matt Anderson (HP) - MA
Paul Moore (HP) - PM
Klaus Weidner (Atsec) - KW
Darrel Goeddel (TCS) - DG
Tentative Agenda:
SG: we need to remove the audit item from the agenda, I have not seen any
issues with that
KW: I have an item on audit, regarding the pam_loginuid model causing sshd
to segfault.
SG: ok, we need to add a section about bugs to the agenda then
GW: I downloaded the aide package and built it on ppc64, and tried it with
james config file, I am making progress and spending time to see what I
need to take out of my python program, I think most of it will be
changed. By the way, I do have a section in the agenda for bugs and
remaining tasks.
Kernel update
-------------
GW: any new kernel issues, any problems with the .52 and latest beta
LS: no problems that I have seen.
GW: we have not installed latest beta since we only have client, from our
point of view, we need to get 390 builds, we have not had those
recently, I know you guys don't control that, but there are some
blockers there. Is it ok to try to verify those bugs with just client
images. can we verify on client?
SG: I know there are no differences in packages. It should be identical
packages between client and server
KW: what about base selection, we are using the kickstart(KS) to have the
base packages installed. Is that the same set of packages
SG: I don't know, I haven't played with the KS. I know that the same
packages on client and server are identical, but not sure if the base
install set is the same
GW: we need to try and see if we get the same set of packages for base
KW: we can use rpm -qa to check base set, but you are saying that same
packages are identical on server and client
SG: yes
GW: we'll at least verify with i386. Ok, we'll discuss this further later,
but how is networking looking on .52 kernel Joy?
JL: some of venkat's socket code for MLS transfer code was not there, venkat
gave me a patch and that worked. TE part works, but I am still concerned
with the MLS part. the MLS label doesn't look correct to me; my SA still
seems to have wrong MLS level based on label of the subject
GW: you expect the level to come off the flow?
JL: I expect it to be at the socket level
KS: In general enforcement happens between a subject and their communication
partner, usually subject and socket will have the same label unless in
case of trusted subjects. So please don't test with ping since it is a
special program, and trusted. Use regular tcp or udp
JL: ftp and password
KW: yes, or even use plain telnet, wget or stuff like that
JL: so my mls level should be of person that issued the program
GW: should be the same
JL: this makes me wonder why we have security context in the SPD then if it
is not used?
KW: It is supposed to be used, networking layer has no concept of users, so
you need to copy properties to be processed. it is indirect, but no
translation is happening there
JL: all we use the SPD entry is to do a poll match, that does an MLS check?
KW: yes, it does. The check is supposed to happen for incoming packets. I
don't know how it works exactly, but it uses two separate mechanisms
JL: in that case, everything looks good to me then
GW: current kernel is looking ok?
JL: yes, with the current testing I did, I'll do more testing though.
GW: without venkat's patch?
JL: No, with venkat's patch, you need that on .52
GW: Ok, so in general what about the rest of it. does it seem stable?
JL: I have not done any stress test. I'll do that tonight to see how it
stands up to it
GW: that would be good. We don't know when the patch will go in, and what
others we need
JL: venkat implied he was working on a better MLS patch
GW: we'll talk on more detail in a bit.
JL: ok, so based on the patch and what klaus said, it seems fine
GW: so you need the patch
JL: yes
GW: did it go upstream
JL: not sure, he said he was working on new MLS transform patch. I assumed
it includes the patch I need, but I'll email him and ask if he will
include this in his new patch.
Beta / Rawhide
--------------
SELinux base update
-------------------
MLS policy issues
------------------
GW: any policy updates?
MA: I am still waiting on policy update, didn't make it upstream yet.
DW: which one?
MA: MLS write in range, to have ranged printer device files and security
server allow write access as long as it is in range
DW: you wrote a patch for that?
MA: I sent something to the list and chris responded. I don't think he put
in the reference policy. There was lots of work being done, so I think
it got dropped. I can email him again and remind him about it. I just
wanted to bring up this one more policy thing to get in
DW: I just didn't update.
GW: would it help to open a bug
DW: it always helps to open a bug
SG: everything needs a bug to pull in the beta
MA: my earlier cups bug is not completely closed
SG: It should be in a modified state
MA: I'll open a bug on that, but I'll also remind chris
DW: I don't mind taking your patch, but would rather not take it in and have
it change, so I prefer to take it from upstream
DW: there are also some breakage in crond patch, so I submitted patch to
crond maintainer.The way you have to write crontab policy is not as I
hoped. There seems to be a problem, it works, just no user friendly
GW: so you are updating the bug on how to do this?
DW: you have to put a context but it has to be reachable from crond.
GW: I see .. that is convoluted ..
DW: I will see if I can get it better, but it works now ...
LS: Dan, I have a bug that I am verifying with crond, and I was running into
some problems. So can you tell me the bug number so that I can see if
some of what you have in there might help me
DW: It is 207433, the last policy is 2.4.3, available in my people page. we
are waiting for update of beta, it will be in beta 2
KW: I get "you are not allowed to access bug 207433", it is not accessible,
can we resolve that
IB: I have been trying to open all the bugs I know about.
KW: could we agree on process that software bugs are interesting, can we
forward them to you Irena to open them up
DW: by default, all issue tracker bugs are closed.
GW: Ok, that makes sense, I am adding you klaus, I have access to it, when
people have interest, I'll add them to the cc list so they get
visibility.
IB: you can make a comment, you can ask that the bug be open for these some
people and I'll open it
KW: thanks
GW: any other policy issues
Newrole & VFS polyinstantiation
---------------------
GW: what to do about this, klaus proposed that we restrict access to newrole
to authorized admins only, seems like a reasonable suggestion
SG: I think there is another discussion to solve the same issue through pam,
james antel is looking into that
JA: that was my understanding for a resolution, you still need to have
different roles. so as well as allowing newrole there had to be other
ways to do it, so we can add it to pam to choose what level you come in
as same thing on sshd
KW: several levels of solution, pam is the right long time solution, this is
for the people who want to do multi level login
JA: login at terminal level, it's not about info leak, you need to login at
different roles
KW: good to have, but not much problem in practice. the pieces we have right
now involve restricting newrole to admins, and not have pam solution,
but as work around, we have multiple unix login names. It is ugly, but
we have something consistent. in future we can have pam instead of
multiple login, nice but not necessarily to have for this rhel5
GW: yeah that would be good to have a clean nice solution
KW: if it is there for rhel5, it is fine, but it will not so much for
testers, since they have to restructure the tests. If it works it'll be
nice, if not we can use multi login names
SG: that's what we were thinking too, restricting newrole
KW: restricting newrole to admins is right solution regardless if pam is
working or not. if people don't see that as a problem, then they can
downgrade that file
DW: how do you envision becoming an admin
KW: login as staff_u then do su to root then use newrole
DW: so newrole is protected by DAC permissions
KW: yes, executable by user
DW: but doesn't help if I ssh in
KW: if you ssh in you are still able to do admin work if you don't change
your MLS level.
DW: should newrole policy not allow to use sudo terminal for changing levels
KW: it leave small exposure if admin uses it wrong, but it is less of a
problem than all users having access. currently there is consensus if
pam solution works, it is nice, but we are not Dependant on that.
Of course the sooner we see a preview of what that looks like, it will be
easier to integrate it
JA: I'll post to the list by tomorrow
GW: great, thanks. that solves the downgrade path through PTY problem. How
is the patch to newrole going Mike?
KW: The goal would be that newrole does right thing when suid, but doesn't
need to be suid
MT: stephen smalley responded to my latest send, had few comments. He was
wondering if people want to preserve environment across newrole.
currently it resets environment to sanitized state. su has this
functionality with -p flag, this is easily implemented but not
currently. If people want it I can do that
GW: stephen thinks you need to do that?
MT: He wanted to know if people want it. The other things are minor
GW: so goal is to get that upstream and in Sourceforge project
MT: yup, going slow but steady
GW: anything else about those
KW: one thing to look into, nice to have a patch to newrole and pam_model to
plyinstantiate on numerical user id. Not sure if we want to change the
behavior, or have option to do either one. this is backup plan in case
we don't have pam model choosing
MT: would you want polyinstantiation to be shared across. I see that the
case of having polyinstantiation on uid to be valuable. in terms of
evaluation don't you want polyinstantiation to break up based on level
KW: let's say you have user smith and smith-secret, if user smith is coming
in through ssh secret connection, then you will be getting in as user
smith-secret
GW: it would be nice to have this as an option. more flexibility
KW: by the way polyinstantiating home directory is a pain in the neck.
GW: other issues?
PTY leakage
------------
Audit userspace
---------------
GW: other audit issues ...
MT: small question, so the vsftpd package which is an ftp server, does not
generate audit messages for anonymous login
KW: it doesn't, since anonymous doesn't have context is not identified
MT: ok, I didn't know
KW: it is not required in LSPP, since it requires identification and
authentication, but not valid if you are anonymous
Print
------
GW: anything else matt?
MA: did testing with policy that dan released. I started actually stopping
to look at print. I focused on KS script on our end and some
polyinstantiation stuff. for now I will consider cups done.
KW: if you have feedback for incorporating that in KS, contact me
MA: that's the plan klaus
GW: I'll keep this on agenda for another week
MA: at least for one more week, until policy is resolved
DW: there is policy update for that range stuff, but not in yet
CIPSO
------
GW: any cipso updates?
PM: policy should be in mainline reference policy tree as well as rawhide
MLS policy. I expect it in rhel5 beta. I've done good stuff for netlabel
control. is it in rawhide steve?
GW: yes
PM: all testing seems to be working as expected
SG: should be in latest beta.
PM: all I have to say, I think we are in pretty good shape.
IPsec
------
GW: apparently from what Joy is saying, there is patch for .52 kernel to
have MLS work correctly. it is getting type part from wrong place. is
anyone from TCS on phone?
DG: I can tell what I know. I think there are few issues that venkat fixed
in secid reconciliation patch. we are trying to pinpoint those issues
and make separate patches to make sure base stuff work correctly. if
anyone has specific issues, he will get that split out of the patch. if
there is anything else that needs to be split out, email him.
PM: Darryl, we can't hear you too well, can you repeat please
DG: we will split out bug fixes in secid reconciliation patches. The issue
joy talked about, I mentioned to venkat ans he is working on it. if
there are any issues, let us know and we'll also split that out.
GW: sounds like a good plan to me. so I guess we are expecting another patch
set this week?
DG: not sure what he is doing, we are moving, so not sure what he did last
week
GW: oh, you mean you are physically moving
DG: yes, moving offices. I'll make sure we have patches out very soon
GW: good to get that in new kernel. and Joy you would be interested in
testing that. sounds like good news. anybody has objections or points
you want to raise about that? sounds like we need pieces in to make MLS
work. we'll leave it there, and not try to do integration with secmark,
is he gonna do that or later?
DG: not sure, we decided that kernel will not meet our needs, so we'll
provide our own kernel anyway and refine it on our own
GW: we will have an lspp kernel, do you think this will meet your needs
DG: don't really know, people don't seem to be understanding each other, we
will use it, build it and refine it and once it works, we'll push
something later. I know venkat is working on this.
GW: hope will be that this will get resolved. and we'll be using similar
bits, but I can certainly understand your need for kernel to meet your
needs
DW: me and chad will talk to him again, and get a status on where we are
GW: if we get something for lspp, cipso will be there, but will not serve as
forward solution
DG: what we would do ourselves is the forwarded traffic, the MLS will be
upstream
KW: I am getting the impression that the controversy is about Types and TE,
and what the labels mean in this context, and not an MLS problem. I
guess cipso has advantage since it has simpler model .
DG: idea that labeled ipsec should give full context, don't see how that
works.
PM: cipso is easier because you have security attribute in sk-buff, that
makes it a whole lot easier to deal with. in ipsec you don't always have
that
KW: as far as TE is concerned, people have different understanding of what
label should be and where it gets set
GW: looks like lots of good discussion, but we have a time barrier. at end
of day we need to produce something useful for the customers
DG: we need to get bug fixes in secid conciliation patch, so we are
splitting it to push smaller pieces upstream and have MLs working
flawlessly. and keep working on the forward flaw patch. we want to get
basic things working and work on others later
GW: I hope we can complete that work and put it upstream to have usable and
maintainable solution. It is disheartening to hear to be honest, but I
understand. we'll do what we can with what we have now.
DG: it is disheartening to us too, we had the design a month ago and was
hoping we'll get it all in, but things change and we need to adapt to
it.
GW: thanks for the update Darryl, if people have comments to add to that. I
don't know at what point RedHat will take what is there, what will be
sufficient to meet lspp minimum from ipsec point of view. it will be
disappointing to have cipso only. this gives up a subset of compartment
and ipv4
DG: labeled ipsec is a complete solution. basically the secid reconcilliatin
we will pull back on. but labeled ipsec is something that should be
done. For example, what joy had, we'll split that separate and push
upstream. labeled ipsec looks good on my book
KW: might want to require ip forwarding to be turned off
DG: most machines do not need it, but I have some that do
SG: is eric paris on line. I'll talk off line with him. the issue that joy
brought up, we'll take care of that soon, but we need bugzilla and a
patch, if not in beta, then in lspp test kernel.
PM: all the lspp beta bits will be in 53?
SG: yes
GW: when you get new kernel, joy will test with it and report results. most
important is to test and find the missing pieces that TCS needs to know,
so focus needs to be MLS
JL: also report policy issues?
GW: yeah, anything .. report to owner and copy list
KW: get in touch with me if not sure about the behavior
GW: and open a bug for it if it needs to go in
Labeled networking stabilization
--------------------------------
xinetd
-------
GW: any xientd issues
PM: I have one, Steve is working on patch to get ....
SG: bug still open, hoping to look at that tomorrow
Self tests
-----------
GW: got James antels modified aide, with SHA-256 and extended attributes,
built that and will incorporate that in self tests and get rid of rpm
database checking and md5sum checks. 95% of self test will go away. if
you have ideas that you want to see, let me know. I am working on that
this week so will produce an iteration in next 7 days.
Cron, tmpwatch, mail, etc.
---------------------------
GW: Dan mentioned some issues about sending mail, and running context.
sending mail is something that needs to be tried and tested.
Bugs / remaining tasks
----------------------
GW: if there are any issues, deficiencies, please open bug to track it and
copy irena
KW: regarding the segfault in pam_loginuid, steve, if you have any idea,
then please let me know, since gdb is hard to use in this case
SG: is this a bugzilla
KW: issue tracker.
SG: did not see bugzilla, but we need the maintainer to pam to be on there
as well. there is some disconnect between bugzilla and issue tracker it
seems
GW: not automatic to have bugzilla if you open an issue tracker.
KW: ok, I'll check and get back to that.
GW: any other issues to bring up. ok we'll adjourn the meeting. Thanks
everyone
Final cutoff date
------------------
More information about the redhat-lspp
mailing list