[redhat-lspp] LSPP Development Telecon 11/13/2006 Minutes

[Loulwa Salem]

HI,
Sorry for the delay .. been very busy


11/13/2006 lspp Meeting Minutes:
===============================
   Attendees

   George Wilson (IBM) - GW
   Loulwa Salem (IBM) - LS
   Michael Thompson (IBM) - MT
   Joy Latten (IBM) - JL
   Steve Grubb (Red Hat) - SG
   Eric Paris (Red Hat) - EP
   Dan Walsh (Red Hat) - DW
   James Antill (Red Hat) - JA
   Lisa Smith (HP) - LMS
   Linda Knippers (HP) - LK
   Amy Griffis (HP) - AG
   Matt Anderson (HP) - MA
   Paul Moore (HP) - PM
   Klaus Weidner (Atsec) - KW


Tentative Agenda:

     MA: Klaus, did you see my patch for your kickstart scrip? I sent it to
	mailing list and copied you I think.
     KW: didn't see that yet, I'll check it and email you
     GW: I hacked on my self tests Matt. I am not getting back what I think I'll
	get for the python bindings. do you know much about that?
     MA: not much .. no
     GW: the methods are not really behaving as I expected. Apologies for the
	mess with the call in number. It was the previous project manager's
	number and I didn't transfer it to my name. We'll wait a bit for RedHat
	people to join.

Kernel update
-------------
     GW: So are people having good luck with the .55 and latest beta.
     LS: It seems fine to me I have it running on two systems. Do we need to
	resolve the issue regarding the kernel panic on first boot, and having
	to boot the first time in enforcing.
     GW: I think that it is due to the kickstart, things got out of sync somehow.
     PM: we haven't seen that, but we have not been testing with lspp kernels
     GW: I also saw an issue with initrd and LVM. it couldn't find my root
	system.
     PM: we'll keep our eyes open if we see it here
     GW: maybe if we do a new fresh install we won't see the problem again
     LS: I did a new install with the 1102 beta, and still saw the problem
     KW: I installed this weekend and that worked fine. Try it again and if you
	see any problems let me know because that shouldn't happen
     GW: someone overwrote the versions I had.. so I'll try that again
     PM: I've seen a problem when auditd was not started on a first boot, and it
	would hang until there is a command entered.
     KW: maybe related to activity on /dev/random
     SG: auditd doesn't even touch /dev/random
     PM: it seems the machine doesn't start up all the way, and you'd have to go
	to lab and give some keywords and it continues booting.
     SG: go into init script and tell it to do an strace. maybe that will give us
	some clues
     PM: not necessarily clear it is auditd, it is waiting for ok before it
	starts
     SG: see the strace to see if it makes it through the daemon.
     PM: the tricky part is that it is only on the first boot. we've only seen it
	on ia64
     GW: I have seen another problem where console does not show a login prompt,
	but it's fine to ssh
     MA: I was seeing that, but if I press "enter" I would get one.
     GW: I was not getting anything even with pressing "enter". so that was the
	other first boot problem, maybe an artifact of the kickstart process.
	I'll look for AVC and come up with reason why that is happening.

Beta / Rawhide update
---------------------
     GW: any other issues with beta. other than the fist boot issues. I had good
	luck so far with the installs.

SELinux base update
-------------------
     GW: ant selinux issues Dan?
     DW: A big controversial one is sysadm being able to read audit logs at
	systemHigh. there is bugzilla where I say I don't think we should fix
	this. first, it is alot of changes in the policy, second, we are not
	buying our selves any security if we do that, so I am apprehensive.
	Right now sysadm has privilege to read/write all file types. I attempted
	to change the type of audit files so that it is not writable by sysadm,
	but that caused problems, so I reversed it. I thought about it and we
	really can't protect those files from sysadm. The reason we wanted to
	separate auditadm and sysadm is to prevent accidental changes. but
	sysadm needs to be systemHigh and if he does that then that is a
  	malicious user
     MT: now that I heard explanation, it's fine from my perspective. if it is
	fine from lspp cert point of view, then I'll say let's close it
     GW: it is fine from lspp certification point of view.
     DW: sysadm is very powerful as well as secadm. as we move with rbac, we'll
	break it into smaller roles. If someone is sysadm, they have a lot of
	privileges anyway, it is difficult to stop sysadm from doing anything
     GW: it is nice to have, but we don't want to drastically change anything at 
this
	point.
     KW: from cert point of view, it is not important. lspp profile is not
	specific about roles on system; I think it is ok that sysadm is powerful
	role and reads audit log. it'll be nice to keep admins from accidentally
	changing the system, but if they want to do that, then there is no way
	to change that
     DW: I don't see where we will be running sysadm at SystemHigh anyway
     KW: yup .. it's ok
     GW: so you'll close the bug
     MT: yes
     DW: there are many policy changes going on
     KW: I posted to the list about this, there are unclear things in mls
	constraints. so far I have not seen justifications, they may be some
	cut/paste errors. unless someone speaks up about why they need to be
	there, we need to change that
     DW: waiting for TCS to comment on that
     KW: looks to me like cut/paste errors which happen to work if you are at
	equal levels. I can work out a patch to fix this if we don't hear from
	them
     GW: do you have bug open
     KW: I hadn't done that. but I'll open one
     MA: Dan I might have policy updates for the usb cups. It has something to do
	with bi-directionality with usb printer.
     DW: also was looking at init problem.. pam tally logs on an authenticate, 	
	but goes down on session. I don't think run init uses session
     SG: need to see how we can fix it
     DW: I can fix run init to use session
     SG: session has ability to mount. there is no pam module that does those
	actions. session start/close with pam-tally
     KW: at the moment I have it configured to use pam_tally in system_auth file
	which is used by everything
     DW: looks like ...
     SG: one thing is that in rhel4 we put pam-tally in each service at the entry
	point. I want to think it was on case by case bases
     KW: if it is a problem, I can put it on individual entry points of data. I
	am assuming that run init ..
     DW: not sure why they didn't do pam session. we'll keep this one online 
now, 	no reason why not to do session for those programs
     LK: is there bugzilla for this?
     DW: no
     LK: should there be?
     DW: yes, so klaus will you add bugzilla
     KW: yes .. I checked previous evaluation, and there was pam_tally in auth
	file

MLS policy issues
------------------
     GW: any other pol type things?

PAM, Newrole & VFS polyinstantiation
------------------------------------
     GW: have not played with level selection path since last week. verified I am
	hitting pam problems which is making it behave strangely. I'll reinstall
	this evening and rebuild patches see how it looks. I'd like to get klaus
	to take a look at that.
     KW: ok .. yeah
     GW: what about newrole patch
     MT: little activity last week, nothing major, mainly trying to get grasp on
	patches. it's been third send for this patch set. no major negative
	comments. in latest send, there has been no negative comments, i guess
	that is a good thing. I'm sitting on it, don't know how to proceed from
	this point, when would I send it, also we are getting close to holidays.
	if anyone has advice on what would be good way to proceed.
     DW: did you get ack from stephen?
     MT: has not seen any ack, though this is third send ..
     DW: I'd just send him a note
     MT: alright, I'll do that
     GW: has anyone else had problems with pollyinstantiation?
     MT: newrole packages in the policycoreutils_newrole, is that the same
	previous one
     DW: yes, just spec file changes
     MT: non uid 0 cannot execute newrole. I have not tried this, but people who
	tried that in enforcing/permissive mode, you cannot authenticate
	correctly if you are not root
     GW: current beta?
     MT: yes, with kickstart install
     DW: what's happening is you are not able to read shadow file. pam gets
	confused and thinks you should be able to. it should work like selinux
	in enforcing mode. you are basically getting permission denied
     KW: just tried it, in /var/log/secure there is message
     SG: maybe labeling problem
     KW: this is in non enforcing mode
     MT: wasn't seeing avc messages
     DW: probably the last raw in config file .. so I'll change config to use
	pam_tally only for the entry point rather than all other services
     KW: if you used kickstart, then you are using /var/log/tally.log
     GW: is this new to this kernel
     MT: yes ... it was getting denied so authentication fails
     KW: keep in mind newrole is not suid, and it doesn't have perms to write to
	tally.log
     MT: it is suid on system I just installed in case you need to address that
     KW: I'll check on that.
     MT: newrole only deals with caller's password and if audit is enabled, it
	checks the auid
     KW: ok, I'll change that and send out a new script
     GW: any other issues with pam and authentication ..
     KW: So, I won't open bug for the init, since I'll fix that with putting
	pam_tally at entry points.
     GW: sounds like a good way to fix it. anything else?

Audit
------
     GW: anything new on audit
     SG: no

Print
------
     MA: I ended up finding problem that eduardo is running into. it is that
	pspdf is not running. once you install ghostscript that fixes the
	problem.
     LK: is that in kickstart script patch you sent to klaus
     MA: I'll have to send that to him. also I found that printer is not getting
	connected. maybe selinux policy issue.
     LK: does it work in permissive mode
     MA: no. but this is on kickstart installed mode.so maybe a missing package.
	I am looking into that usb interface is working correctly. one good
	thing /dev/usb0 uri and the hp/lexmark uri both have same error. the
	benefit of that is we'll use fs to do the limit on the uri. not looking
	for something specific to vendor/model uri. another thing, looking into
	way to setup printers in through the lp admin program. if there was some
	RH specific things we would need to make sure we capture and document
	those. I'll check that we are not dropping something RH specific.
     GW: great
     MA: has anyone tried the network config .. it seems like it is missing some
	dependencies
     GW: we need to revisit the package list and check
     MA: I'll look more into that and send out a not about missing pack

CIPSO
------
     PM: there was some issue last week, but we resolved that. all my testing so
	far looks pretty good. I ran through network relevant test in LTP. it
	looks like we are in pretty good shape.
     SG: one thing that came up last week, while reviewing joy's patch for ipsec.
	I forgot to look at your patch to see what would your patch do if audit
	is disabled. if audit is disabled, there should not be any audit
	message. I forgot to look at that in your patch. if it produces
	something, we need another patch to prevent audit logs
     PM: should that be handled in the audit subsystem
     SG: programs skip all the setup work. if audit system is disabled it
	shouldn't need to go through the work.
     GW: should we expect another patch
     PM: I'll try that, look at the code and send something. if I do send patch,
	it'll be really small
     SG: sounds about right, probably 2 lines of code at the entry points for
	audit log. I think there was an inline static function that did the
	check.
     GW: joy, how did your audit patches go for ipsec
     JL: so far so good. I sent them friday. I have the .55 kernel. so I'll run
	some stress tests. fernando and I are going through setting up ipsec
	without enforcing mode. the rules we are encountering we'll send out to
	the list
     SG: I'll take a look at the audit patch and I'll send you the feedback
     JL: thanks. that's all, saw the venkat did additional patches, and wanted us
	to try against 2.6.19. should I test the lspp.55 or get the 2.6.19 and
	put patches on it and test with that
     GW: get src.rpm of .55 kernel, patch it and test
     JL: ok, I'll do that. are there any of venkat's patches in .55 kernel
     EP: which patches ...
     JL: venkat had set of 3 patches
     EP: 55 has all three patches
     GW: do we expect more patches from venkat
     EP: I don't know of any. I am expecting the 3 config change patches
     JL: I saw klaus's mail about policy. maybe I want to get those cleared up
	before we get the ipsec policy.
     KW: start on testing and see what current behavior is.
     GW: so you'll be writing policy and doing stress test. when do you expect to
	have policy updates.
     JL: I'll try to get it done in next 3 days. we're just seeing alot of denied
	messages in enforcing. so it is best to iron it out.
     GW: any other networking issues
     PM: steve, got xinetd fixed yet?
     SG: no
     LK: eta
     SG: I'll try to get to it soon. still got lots of things in queue. I'll try
	to get to it this week.

IPsec
------

Labeled networking stabilization
--------------------------------

xinetd
-------

Self tests
-----------
     GW: I hacked on that a bit, but steve, I did not find the python bindings to
	work as I had expected
     SG: ...
     GW: when I get status, what do I expect
     SG: you'll get structure from the c code. three or 4 things in there are
	interesting
     GW: should I instantiate an object and use attributes from that object
     SG: I really don't know enough  about python to tell you, Dan?
     DW: you called the audit status? I'll try it now ..
     GW: so how do I access the members?
     DW: I tried it and it's broken .. I'll see if I can fix it. it should return
	a list
     SG: if you do auditctl -f you'll get something similar to that in a
	structure form
     GW: looking at man page, it is not clear how to use that .. man page maybe
	broken as well
     SG: ok, it's a two part call, you request the status, then you have to do a
	get_reply, then you pass that a structure and it should be populated
	there?
     GW: ok, that makes sense.
     SG: it returns to you a sequence number, you don't need to do anything with
	that seq number, but next thing to do is get_reply
     GW: that fetches info and puts it in buffer ..
     SG: yes, audit_get_reply function
     GW: so I need to do something analogous in python and expect a thing out of
	that.
     SG: I think it should spell out that you need to get audit_get_reply in
	there.
     GW: I'll send a patch to that
     SG: I am slowly working toward audit.2.10 intended to go in rc1
     GW: As for aide, I have not worked with policy. when I install I'll try that

Cron, tmpwatch, mail, etc.
---------------------------
     GW: is cron working as expected now ..
     JA: last half of week, they found really small changes
     GW: ok, we should all be testing on that. have you tried it with having send
	admin mail
     JA: no
     GW: it's something we need to test and no one did that I think
     JA: ok, so this is not mls changing problem
     GW: shouldn't be, it's a wrapper around mail program. we decided it was very
	useful and expected. alright.. any general issues .. ok, everyone write
	bugs, please bring up on list and let's just keep it up. Is there
	preference to have meeting next week? ok, we'll tentatively have a
	meeting next week then.
     SG: there are few things to get out of agenda ..
     GW: like audit
     SG: yeah .. I think we can shorten it up.
     GW: maybe reordering of the agenda as well
     SG: cups also ...
     PM: nothing going on there
     GW: maybe, we'll have a list of development items and some bugs section.
     SG: everything that is done and bugs only, let's have that in bugs section.
	everything that is still open and has development we'll keep that open
     GW: should this meeting turn into bug tracking meeting?
     SG: sounds like it's time to do that
     LK: looks like it is happening that way already ..

Bugs / remaining tasks
----------------------

Final cutoff date
------------------