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
------------------
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
