[redhat-lspp] LSPP Development Telecon 01/22/2007 Minutes

Loulwa Salem loulwas at us.ibm.com
Tue Jan 23 21:41:42 UTC 2007


01/22/2007 lspp Meeting Minutes:
===============================
   Attendees

   George Wilson (IBM) - GW
   Kris Wilson (IBM) - KEW
   Loulwa Salem (IBM) - LS
   Michael Thompson (IBM) - MT
   Joy Latten (IBM) - JL
   Kylene J Hall (IBM) - KH
   Irina Boverman (Red Hat) - IB
   Steve Grubb (Red Hat) - SG
   Dan Walsh (Red Hat) - DW
   Lisa Smith (HP) - LMS
   Amy Griffis (HP) - AG
   Matt Anderson (HP) - MA
   Paul Moore (HP) - PM
   Klaus Weidner (Atsec) - KW
   Chad Hanson (TCS) - CH
   Joe Nall - JN
   Ted Toth - TT


Tentative Agenda:

Kernel / Beta / rawhide update
===============================
     GW: So we can chat a bit until others join.
     MT: I found out from Dan that there is a boolean to be able to login as
	sysadm_r
     GW: and the types file as well, is this documented somewhere?
     DW: this was an old one so I forgot to mention it. Booleans are not very
	well documented
     GW: yeah, I had to look up some stuff earlier for my work as well. As we run
	across things like this, should we open documentation bugs?
     DW: not sure where to document them though
     GW: fedora wiki used to be available
     SG: It should be still open for that
     GW: Klaus used to post and his permissions got revoked and he had to sign a
	multi page document to reactivate it so he stopped posting
     SG: this is mainly from the fedora project to make sure this info is freely
	available and any posting are not copyrighted material
     GW: ok, so just an FYI that we have not been posting there
     DW: we should be opening documentation bugs I think
     GW: Kylie had asked about the off by 100 hex in certain syscalls. I didn't
	know where to document that so I've been encouraging everyone to open
	doc bugs, hopefully that's what we need.
     SG: this one is a bit harder to track since it is a glibc change. so if it
	changes no one would notice for a while.
     KH: seems like documentation in man page for those syscall would be 	
	sufficient to at least indicate this is what is going on under the
	covers
     DW: in my defense there is a place in /usr/share/doc/selinux-policy, there 	
	is an html directory and in it a global-tunables file. I'll send a link
	to list with that.
     MA: I was trying to set some booleans on my system and I got an AVC. just so
	you know
     DW: I think if you do restorecon on /etc/selinux/mls it should work. Did you
	run in permissive at all? usually means you have mislabeled modules
	directory. If you can figure out how you got it mislabeled that would be
	good
     MA: it is complaining about the active modules directory. I don't think I
	broke anything on this one though. it was a fresh install
     DW: if you figure out how it happened, we need to know. but if you want to
	fix it just do a restorecon. Anyhow, there is lots of policy
	documentation out there
     GW: good. It will give me something to point people to. that is immensely
	helpful. So how is the current build?
     JL: for me great, with kernel .63, the only problem I saw was that tcpdump
	seems to crash kernel and go into debugger.
     IB: I spoke to kernel engineers on that so maybe you can help answering
	those questions they have on the bug
     JL: I opened 2 different defects and been trying to keep them in sync. I
	only see it on .63
     GW: so you are working in RH defect
     JL: yeah. only in  63. with any other one it works fine
     IB: I can tell you the questions they posted to the bug: can someone verify
	tcpdump works on other network adapters? and ...
     SG: we had a patch that went out for ppc. there is a concern about that
	maybe having some unintended effect. we are mostly suspicious of the
	ethernet driver. I tried tcpdump and it is not crashing anything, the
	problem seems specific to ppc. I think we really need to solve it
	fast. we can't ship kernel like that and we are past cut off date for
	kernel
     GW: was that in an lpar
     JL: yeah
     GW: that was the virtual ethernet driver then
     JL: true maybe some changes happened there.
     GW: maybe see if vio-server partition threw an error. just guessing
     JL: Ok, I'll try it. not sure where to look for info though
     GW: syslog on the vio-server. that will probably be the only driver unless
	you configured aliases
     JL: nothing like that. it is a regular system. I'll try that and see
     IB: there is a comment that says it used to work on other kernel versions
     JL: yes, I have rhel5 rc7 installed and I put .63 kernel . if I remove the
	63 it works fine. It could be the IBM V-eth. I didn't see this on .62
	kernel either
     GW: did you get stack trace
     JL: no it doesn't give you that
     GW: does it drop into xmon
     JL: yeah, what I got I put in the bug, but I can't get a backtrace. not sure
	what's going on
     GW: that's unfortunate. what else can we do to help move that one along,
	sounds like a bad one
     SG: yeah it is. I'll talk to Eric.
     GW: does this need to be raised to a ship issue
     IB: already did that
     SG: we know people are going to use tcpdump, so we have to fix it
     GW: if it is a ship issue, I'll ask for status daily
     SG: it is a ppc specific bug
     GW: if it is v-eth, we might get virtual device driver folks involved now as
	well. Other issues. So everyone knows about removing selinux-pam module
	from the ssh config file. we should document that somewhere.
     LS: I don't think it is necessary. that should be fixed with the latest
	kickstart I believe.


PAM and VFS polyinstantiation
==============================
     GW: I don't think we need to talk more about this
     DW: polyinstantiation library is somewhat broken. Did you get my email about
	that? The unmount doesn't' work if you don't set up root
     GW: is that fixed
     DW: fixed in fedora but not rhel. we need a bugzilla to carry that through
     GW: you expect that to go in GA
     DW: it will be carried in, but needs bugzilla


ssh level selection
====================
     GW: and level selection is working ok?
     MT: yeah, unless with using our custom policy.
     DW: what are you guys trying to do
     MT: With our super user abat, we can't specify a level to assume. it has
	full range, but we get user-role log that shows an error.
     DW: just send me the .te file and I'll try to debug it.
     LS: Another issue, I had to add some extras to the default_types file
	(devpts_t changes). Is that something we need to keep adding?
     KW: yeah, you shouldn't need to do that unless you need that for newrole
     DW: that is used by newrole now
     LS: Oh yeah, that was needed to do newrole -l, so I don't need to make any
	changes now since we are using ssh to select the level.
     MA: is that the types file, because I added something to that and it wasn't
	all owing me to ssh
     DW: you need the latest policy. You need to do ls -Z on the tty to get exact
	string to use.
     LS: you might have to comment the pam_selinux.so line in the pam.d/sshd
     MA: I am seeing this when using expect. but I think I have that pam_selinux
	flipped off I think. Thanks


IPsec localhost, IPv6, 1st packet drop
======================================
     JL: everything looking good for .63 . was able to complete stress test for
	ipv4 and ipv6 for regular and labeled ipsec. Dan I mailed some policy
	this afternoon and it's a shortened version of what I think is needed
	for ipsec to work in enforcing mode. I'll test out a bit more but it is
	ok so far. It is short version of patch I mailed out before. Other than
	that ipsec is looking good. The other outstanding issue I see is the
	loopback one. Joe Nall sent me a raccon patch that I'll look at this
	afternoon. everything is looking good except one outstanding issue.
     DW: do you want boolean around that policy ...
     JL: in fact I forgot to put that in email. it might be better to put boolean
	around it. I do think we still need the big patch with those interfaces
	in it so policy admin has more control. We do need boolean since what I
	have allows everything
     DW: right since you have it allowing all
     JL: right boolean to allow everything or nothing. I cc'd chris to get his
	input as well. I can ping him on IRC to get his input again
     DW: stuff looks fine, I'll wrap it in a boolean.
     JL: that's it except for loopback issue. I'll take look at Joe's patch to
	see what he did.
     GW: any cipso issues
     LS: nothing at this point, just had issue with our policy, but cipso seems
	fine.
     JN: A question.. is there possibility to get the presentation/paper by James
	morris?
     DW: I would contact him to see
     JN: the patch I gave joy is a start, but it gets me to point on my machine
	to get the loopback issue.
     GW: it looked easily doable.
     JN: It's not complete, but for what it does it works fine ... it needs
	someone to look at it that knows racoon more that I do
     GW: did you look at xfrm code?
     JN: it is good code but with no docs
     PM: anyone looked at kernel code?
     GW: well, some of it ...
     SG: speaking of kernel code, is Amy on?
     AG: yes, I'm here Steve
     SG: You were seeing a problem with audit hooks?
     AG: I think what's happening here is more edge cases around audit inode
	hooks. It looks like that kind of an issue. George you worked on more
	places to collect audit messages?
     GW: yeah, the msgqueue mostly.
     SG: we forgot to bring up this bug earlier
     GW: do I need to do something to help with it
     AG: I am looking at it more to get more info and I'll file a bugzilla. if
	someone wants to look at it as well, that would be great
     GW: I'll try to look at it especially if I created the problem
     SG: Amy want to describe what you found
     AG: with posix msgqueue, when you open one that already exists, we don't get 	
	object label for it, we only get one that is new. Looks like audit did
	not collect inode information. I think it is because it is an edge case
	because we don't have an audit hook. This is just a place that wasn't
	covered. Seems like the problem we ran into last summer where some edge
	cases were not audited and we had to add hooks.
     GW: if it is a simple matter of missing a hook, it should be easily fixable
     AG: I'll open a bugzilla and we can all look at it.
     GW: yeah probably missed a hook.


Self tests / aide
=================
     GW: I just posted an interim version of self test to show evidence of
	progress on it. I am trying to get policy to run with runcon. I created
	policy based on aide policy and added many more permission in there, and
	hope it is workable. It is simple code really, but the policy is almost
	as much as the code. Please know it is incomplete, comments are welcome.
	I added an option to configure it to shut down the system since I
	figured it'll be a requirement. It is what it is now and I'll keep
	hacking on the policy. If additional things need to go in there, I 	
	appreciate people letting me know
     DW: will you publish the policy
     GW: yeah, I put it with the tests on the lspp list


Cron
====
     GW: there was concern that cron was sending mail that someone can log in and
	see results from some job of higher level. one of our testers got cron
	job run with no mail sent. we need to make sure if that'll be the case.
	if by default it sends mail it may be we are downgrading info
     KW: if we do the -M flag ...
     GW: it makes me worry that the system allows this behavior at all. that
	constraints don't behave as expected.
     KW: which processes have more privileges that they don't need. this is a
	side effect that it can change level without realizing that it violates
	constraints
     DW: we can not allow it to send mail
     KW: this is a band aid. the main issue is in an MLS system you shouldn't put
	band aide policy since constraints should be preventing this kind of a
	leak
     MA: is there way to get cron to error out when running at level higher than
	what you are trying to do? I added a rule and it seems to fail silently
     DW: it shouldn't fail silently. it should generate msg saying you are trying
	to do something evil
     MA: I thought I only saw cron and pam message.
     DW: that definitely is a bug
     MA: I'll verify that and then open bugzilla
     GW: klaus put out new version of config kickstart. hopefully will try that
	out this afternoon
     KW: I added big list of patches on top of snapshot 7 and not sure we need
	them
     GW: I think we need those versions.
     KW: I noticed I forgot to put in one of the patches to do the autorelabel. I
	put the fixfile and it seems to work fine in my initial testing.
     GW: I agree with you
     KW: is linda on call
     GW: No she is not, but she will read the notes
     KW: linda graciously volunteered to work on the feature to implement that
	when running config script to get system configured in CAPP or LSPP
	mode. She said she is close to done and I wanted to say this should be
	in the next drop
     SG: Another issue, a long time ago I updated lspp.rules file and we had said
	that in some point in the future we'll get the real list to see the
	files that need to be watched. I think it is time to look at it and see
	if we need to add/remove files from the list
     EP: I think we need to add the changes to aide policy as well
     KW: in previous configs, we need system to have audit capabilities but not
	necessarily running on the system, but ofcourse it is great to have a
	workable starting point
     SG: yeah, people can look at the configurations for audit, read comments and
	work through that
     GW: I agree, a useful set of defaults is great and we need to add it to aide
	policy. where do we get that file from steve?
     SG: it is mostly file watches, and some syscalls and not sure if we need
	more additions. We need to look at all new syscalls and see if they fall
	into categories that we care about. the selinux config files, aide and
	racoon stuff would probably be added to watches.
     GW: this is a time where a wiki would be handy
     SG: or we can pass it on audit list
     KW: good starting point is the capp list from previous evals.
     GW: sounds good, was wondering if there is a way to automate this maybe by
	looking at rpm output
     KW: not all would necessarily be candidates.
     GW: who wants to take first stab at starting the list
     SG: I'll start the discussion on that in the linux-audit list. it'll either
	wind up in kickstart or audit package, and I prefer to integrate it in
	audit package.
     GW: is there a bug open on the first packet issue? It sounds like a bug to
	me regarding the connection where first packet is dropped.
     JL: someone forwarded a message saying that James morris is aware of that
     GW: I think it need to be a bug so we can track it
     SG: Irena, something we need to do is, since we are passed final cutoff
	date, we need to start an lspp tracker bug to track all bugs that fell
	off the list.
     IB: yes, we'll talk about that if you are in the office later. I was
	thinking to do one each for user and kernel space
     SG: I was thinking george and linda would want to hear about that. One
	tracker bug would be better.
     IB: should I do a keyword or tracker bugs?
     SG: I think a tracker bug is better ..
     IB: Ok. I'll do that
     GW: ok, I'll remove final cutoff date from the agenda. Although we will have
	internal deadlines
     SG: I think there is dates like that but nothing to be published I don't
	think.
     GW: ok, I'll remove from agenda. Anything else we need
     KW: I want to revisit the cron and mail issue, I don't think it is the fault
	of mail system. mail system only works at systemLow, cron is using its
	override privileges to send the mail. I think it would be an acceptable
	work around to disable mail delivery via cron. in long term it would be
	better to modify cron.
     GW: we need to audit that through Dan's policy
     KW: just don't let cron deliver mail
     GW: do we care about accidental delivery
     KW: there is an option that people can use. we can add comments in there ..
     DW: dropped off a bit, you want me to disable transitioning cron to mail?
     KW: I think we can ...
     DW: so you'll do something in post install to disable that
     KW: yeah, that should be fine for our config. We might want to remove that
	from policy, but not necessary.
     GW: ok, any other issues? Alright, we'll adjourn meeting. keep on working to
	completion, we are almost there. thank you all





More information about the redhat-lspp mailing list