03/05/2007 lspp Meeting Minutes:
===============================
Attendees
Lawrence Wilson (IBM) - LW
George Wilson (IBM) - GW
Kris Wilson (IBM) - KEW
Loulwa Salem (IBM) - LS
Joy Latten (IBM) - JL
Kylene J Hall (IBM) - KH
Kent Yoder (IBM) - KY
Irina Boverman (Red Hat) - IB
Steve Grubb (Red Hat) - SG
Dan Walsh (Red Hat) - DW
Eric Paris (Red Hat) - EP
Linda Knippers (HP) - LK
Amy Griffis (HP) - AG
Matt Anderson (HP) - MA
Paul Moore (HP) - PM
Klaus Weidner (Atsec) - KW
Chad Hanson (TCS) - CH
Agenda:
Agenda and Meeting Formats
Bug Discussion
Around the Room
RHEL 5+ Packages:
kernel-2.6.18-8.el5.lspp.65
kernel-devel-2.6.18-8.el5.lspp.65
kernel-doc-2.6.18-8.el5.lspp.65
mcstrans-0.2.3-1.el5
selinux-policy-2.4.6-38.el5
selinux-policy-devel-2.4.6-38.el5
selinux-policy-mls-2.4.6-38.el5
selinux-policy-strict-2.4.6-38.el5
selinux-policy-targeted-2.4.6-38.el5
audit
vixie-cron
IB: george we should skip over closed and modified bugs
GW: yes, I just copied all the list, also there are a couple that Lou
mentioned that are not on the list. there maybe others that people want
to bring up. Irena are you going to make edits directly into the
tracking bug.
IB: steve wanted developers to make them directly.
GW: while waiting. I did hack on self tests and policy. I gave base program
massive mls overrides, idea is that it'll kick off a helper in
appropriate domain to conduct BLP test and that domain will lack mls
overrides. I've gotten a helper script that does a read/write of file
at the right level. Joy pointed out I need to add interface to allow me
to get if selinux is in enforcing or not. so once I added that, it
helped in other areas. This is the first time I am able to create the
test files and have an executable. I'll post my work in progress. For
somethings I didn't get AVC like setfscreatecon, it will fail but when I
gave program ability to check selinux mode, it allowed one of the
setfscreatcon to work when it wasn't working before. I got no avc which
was troubling, also found that audit2allow doesn't always give right
rules. Anyway, I hacked on it and gotten it farther than before. That's
my update. I should open bug to say we need it so we can bring it in.
SG: lspp yum repo is up and live as of five minutes ago. it'll have most
recent kernel, it is simpler to keep just one copy. I need to go through
and find the lost packages, acl and kernel are there, and a pam, I
didn't see vixie cron and don't remember seeing policy. I need to go and
see what's going on.
GW: where would we find that
SG: same place, off my people page.
GW: I still see the 65 and 66 kernels
SG: I just updated it ..
GW: ok, thanks for that
SG: I need to get the audit package, and just need to get vixie cron and
policy and we should be good
CH: I see all the old kernels as well
LK: yeah, me too
SG: I went to the audit page, and there is link at bottom that says yum
repo, and my files are there. Maybe something went wrong
GW: any issues before we move on to bug list?
JL: in .67 kernel, when I try to build and make initrd, I get all kind of
permission denied errors in there, I tried it on 2 systems, and I see
same behavior. only time I can build is if I am in permissive.
DW: make initrd?
JL: yeah
DW: are you doing this as sysadm
JL: yes, I get permission denied from mknod /tmp/initrd
DW: make initrd is doing very heavy duty things on system, which we don't
allow it to do
JL: some of avc messages complain that it can't do block file create...
DW: I can add these, but not sure if there'll be a need for them or customer
requirement for that
GW: if we don't fix it, should we document it?
SG: I doubt anyone would install gcc on production system
GW: I agree, so this is worthy of documentation only
EP: it is not a very common operation.
SG: that would be unsupportable
EP: doesn't likely sound it'll ever be a problem
DW: George, steve was saying you were not generating AVCs
GW: I hacked on self tests some , for certain things, I needed to add
interface to be able to determine if selinux is enforcing or not, I
added that and wasn't getting any AVC. That also fixed fscreatcon
failings. I gave my program mls overrides, in enforcing mode
setfscreatcon would fail with no AVC messages
DW: what if you run not in enforcing, does it generate AVC
GW: it works fine, so I don't see AVC.
DW: getenforce is not a privileged action
GW: there is an interface and I couldn't do it
EP: your program didn't have permissions
DW: your problem is that you couldn't read /etc/selinux maybe
GW: why couldn't I get AVC on it
KH: which setfscreate where you using
GW: setfscreatecon
KH: were you running lspp policy?
GW: yes
KH: cause I had to make changes to that for the sockcreate
GW: first setfscreatecon works, but if it create a file at system high, it
fails
DW: and it generates AVC
GW: no
DW: Ok, I would like to see that
GW: I have another way to do it with helper program, but I was surprised I
wasn't seeing AVC with this. I've at least got a way out through policy
and by not calling runcon or the shell, I am simply doing my own
equivalent of runcon. I still have more work ahead. I'll post what I
have and if people can give advice, I'll be happy to see it. this is the
first time I am able to do this. no matter what we have it do, we need
the overrides, so I think this is the correct approach.
DW: just make sure it is not able to do much since it is powerful
GW: that's why I think the helper function is necessary and it only creates
files with specific naming convention, so it is contained. Any other
issues?
LS: Dan, I talked to you last week about the /etc/selinux/mls/modules
context that gets changed in some instances. basically the active
directory context gets changed when using semanage sometimes,
and the next time I try to use semanage, it fails
DW: if you ran semanage in permissive, it will cause the label to change
LS: I was 100% sure I was running in enforcing. Camilo is Brazil was seeing
something similar as well.
JL: I see a problem like that as well sometimes
LS: I should open a bug for this ..
DW: yes definitely ... we can't update anything unless we have a bug
GW: we need very soon to talk about locking things down so we can run formal
testing in next couple of weeks
SG: now that I have repo, we can change easily
GW: yeah, because any changes are going to mean re-testing
LK: we are only fixing things that affect test now anyway
SG: at RH right now, we are locked down
GW: we need to at some point accept no bugs unless they are blocking
evaluation
LK: I thought we are in that mode already
GW: we must be in hard lock mode, I think right now we are in soft lock mode
EP: I think there is one bug that won't block, like the kernel memory that I
know of.
IB: if we don't need to fix some bugs, then we don't close them, but we can
remove them from the dependency list
GW: we need to take absolutely what we have to take
218386 [ASSIGNED - normal - [EMAIL PROTECTED] - ] LSPP: labeled ipsec does not
work over loopback.
JL: been working on it. I was seeing double SAs. I did a test to have
packets using ESP and AH, I was seeing 4 SAs. I was seeing 8 or 16
instead, and I thought maybe it was that loopback patch. the patch seems
fine, but I think there is a bug in the kernel, it is result of the
patch to not drop first packet. for example when you do a ping, it sends
multiple packets, and tries to establish multiple SAs until the first SA
is established. need to look more at it, I might have to send question
since I don't know much about this queue. I think the loopback patch is
good
GW: was this part of Dave miller's patch? it would be good to contact him
JL: yes .. I'll send to netdev
CH: you can copy Venkat on this as well
JL: I'll also document in bug report. since I tested loopback patch, I'll
send maybe tomorrow to ipsec list
223532 [ASSIGNED - normal - [EMAIL PROTECTED] - ] [LSPP] crontab manpages
reference older environment variable.
SG: I think it's fixed. it's a matter of me locating the package and getting
it into repo, so you can try it
GW: should be changed to modified
SG: we'll chase that one down
223840 [NEW - high - [EMAIL PROTECTED] - ] [LSPP] getfacl fails to correctly
display all information about links explicited as arguments.
KW: this is an older bug
SG: this just needs to be verified. it's in the new yum repo.
KW: I had unofficially checked patch and it worked, last question was where
the updated package is and you just answered that
SG: might just be mirroring problem
223864 [NEW - normal - [EMAIL PROTECTED] - ] LSPP: Exceptions to expected audit
behavior should be documented.
LS: we had talked about putting this in configuration documentation
SG: I left it open as courtesy, I am leaving it open so we don't forget
about it.
KH: last I knew Klaus was putting that in our config file. Best way is maybe
mark as "fixed in documentation" and we'll document it
SG: if I change it to fixed, it'll drop off this list
LK: yeah, that would be ok
SG: ok, will close it
223918 [ASSIGNED - normal - [EMAIL PROTECTED] - ] LSPP: audit logs bogus obj
label in some PATH records.
AG: needs to be verified .. I've done that
EP: if you put a comment in there, I'll get it sent for inclusion. I don't
think we figured a way to make those disappear off this list
SG: was very busy, so I didn't look into this
EP: I'll think of something
223919 [ASSIGNED - normal - [EMAIL PROTECTED] - ] LSPP: audit does not log obj
label when opening an existing POSIX message queue.
AG: I've verified, I'll update the bug
225328 [ASSIGNED - normal - [EMAIL PROTECTED] - ] LSPP: ipsec drops first packet
when using IKE daemon.
JL: that's the one giving us problem. I'll send email to Dave Miller
226780 [ASSIGNED - normal - [EMAIL PROTECTED] - ] LSPP: audit of writes to files
of bin_t produces no records.
SG: that one, I have fix for and need to get audit package into repo
228107 [ASSIGNED - normal - [EMAIL PROTECTED] - ] [LSPP] Labels for labeled
printing don't linewrap.
MA: patch is set, I need to get it merged up with RH, and run through one
last round of testing
GW: so we need to add cups patch
228366 [ASSIGNED - normal - [EMAIL PROTECTED] - ] LSPP: audit does not log obj
label for signal recipient.
SG: need review
EP: This causes audit panic in lspp.67
SG: Al said he'll look at signal patch and will maybe show up for some
teleconf
EP: see if Amy has a fix for that
228384 [ASSIGNED - normal - [EMAIL PROTECTED] - ] LSPP: audit does not log obj
label for traced process.
SG: Al sent patch today, need to grab and put into new kernel
AG: I had a question about it, I thought I saw it wasn't grabbing the sid,
it looked like it was doing conversion of string right away, and was
wondering what you thought of that?
SG: I told Al that it was grabbing number and was doing conversion. I
mentioned to Al and he seemed unphased by it.
228409 [ASSIGNED - medium - [EMAIL PROTECTED] - ] LSPP: regular ipsec in
upstream kernel crashes.
JL: that's that transform_audit. Eric, remember that bug I reported to you
where I get the bug in .67 kernel .. that's applicable to this one
EP: I think we have patch for it, just need to look at it
228422 [ASSIGNED - medium - [EMAIL PROTECTED] - ] LSPP: cleanup xfrm_audit_log
interface.
EP: that's the patch I think solves the other one. Who are those assigned to
SG: Al viro
PM: they look like they are assigned to Eric just by looking at the bug
SG: I think they are assigned to Eric since he is doing the kernel build
228557 [ASSIGNED - medium - [EMAIL PROTECTED] - ] LSPP: In labeled ipsec,
permissions are checked after deleting the policy.
JL: that one is one I need to check and close out
EP: I sent fix upstream and didn't hear much from Venkat other than he liked
it
228927 [NEW - medium - [EMAIL PROTECTED] - ] LSPP: odd audit argument on some 32
bit syscalls.
KW: this is also doc fix that we are adding to config guide
GW: should we close it out then and document it
KW: yes.. it's not really error, just system behaves a bit oddly
229094 [ASSIGNED - medium - [EMAIL PROTECTED] - ] LSPP: audit records for some
f*xattr syscalls don't include object info.
LK: that one was verified
GW: need to update bugzilla then
KW: there is kernel patch for it but not sure if it is built in kernel
already
LK: I tested with .65 kernel
EP: I'll find way to get that one off list too
GW: thanks
229527 [ASSIGNED - medium - [EMAIL PROTECTED] - ] LSPP: flow cache entries
remain valid even after selinux policy reload.
JL: I just sent email to venkat on how to test those, same for one below
229528 [ASSIGNED - medium - [EMAIL PROTECTED] - ] LSPP: memory leak in flow
cache code.
EP: this is the one I don't think it is necessary an evaluation blocking bug
229543 [NEW - medium - [EMAIL PROTECTED] - ] LSPP: odd avc message.
SG: I think Stephen smalley explained that one, I think it's closed as not a
bug
KH: we wanted to keep it for things to do better for later ..
GW: so lessons learned, and we'll take it off the list
229673 [ASSIGNED - urgent - [EMAIL PROTECTED] - ] [LSPP] cups is overriding mls
when querying jobs with lpq -al.
MA: I think that one has been released as updated package, we can add it to
repo so we can test around that.
229720 [NEW - medium - [EMAIL PROTECTED] - ] LSPP: pfkey_spdget does not audit
xrfm policy changes.
JL: that'll be included, and I think I need to test it out.
GW: already patched and patch need testing
EP: correct
229732 [NEW - medium - [EMAIL PROTECTED] - ] LSPP: pfkey_delete and xfrm_del_sa
audit hook is misplaced..
JL: that one too
GW: just needs to be tested
EP: yeah, there should be patches and I sent them all upstream
230144 [NEW - medium - [EMAIL PROTECTED] - ] LSPP: panic in audit_receive
filter.
EP: I'm closing it as dup of another one
230255 [NEW - medium - [EMAIL PROTECTED] - ] LSPP: cipso mapping settings
prevents login into system.
LS: This one that turned out to be an expected behavior, but uncovered that
some packages were getting sent when they shouldn't have been. Paul
posted a patch
PM: the patch was sent upstream and quickly acked by James morris and it is
already into the tree, so it is probably good to pull into the next lspp
kernel
SG: so we have two patches
EP: I think there are three patches
SG: I am concerned we are not getting good tests since the kernel is oopsing
EP: I'll come up with kernel that won't oops
230613 [ASSIGNED - urgent - [EMAIL PROTECTED] - Reopened] [LSPP] cups is
allowing users to delete other user's job.
SG: there is ongoing discussion if it is feature or bug
MA: from our perspective, it is a bug .. I sent klaus some lines to put in
config file. for evaluation it is not bug ...
KW: Let me see if I understand this correctly, anybody can remove jobs from
queue that other user queued without authentication. problem is that the
cups never used to check anyway so people think it's not a bug. it's
broken behavior, but we can change config to always ask for
authentication
LK: you can also queue job as anyone else
KW: looks like user it is queued as is just informative or does it really do
something
LK: you get audit log with auid as the real user, but the id is the user you
are impersonating
MA: ...
KY: is there such a thing as printing quotas that can be bypassed
LK: when we configure it to do authentication, the way it uses pam, it
wasn't counting against failed attempts, so you can use it to do
password cracking
KW: is it prompting for your user or password of user you are using in -u
LK: it's user specified with -u
KW: so you can use it for password guessing. this is broken
SG: you can still use the pam tally to count
MA: there is a bug that just got opened (231062) for that
GW: what are we going to end up doing with that, are we using the
authentication mechanism
MA: yes, we have to
LK: we will need a policy change, and config changes to cups
GW: we need to make sure these get filtered to klaus. and I'm sure patches
are all very appreciated
230663 [NEEDINFO - medium - [EMAIL PROTECTED] - ] LSPP: random problems with the
python rpm.
KH: you asked me to open a bug on. I was trying to do something on my older
partition. I think they are waiting on info from me to do memtest 86,
and I don't know how to do that, so I asked for instruction for s390
SG: I think it would be for intel only.
GW: how about amtu, is there another generic test that can be run that is
equivalent
SG: I don't think there is an equivalent
GW: maybe we can ping the s390 people
SG: if you see it on two machines, put that in the bug, so they know it's
not a hardware problem.
KH: I am seeing it on two partitions of the same machine, does that count
SG: I'm not sure
230740 [NEW - normal - [EMAIL PROTECTED] - ] LSPP: ausearch -se doesn't work
with object label.
SG: should get that one through build system in the next day once the repo
is set up
230620 - xfrm_add_sa_expire bug
JL: This is the bug Kent found by inspecting the code
KY: Dave miller submitted patch and I put reference for it on the bug
JL: we need to make sure we pick that one up. Eric can you pick it up
EP: I'll look at it
231021 - amtu -n fails with MLS policy in enforcing mode
DW: should that go in base policy
GW: ideally, it would be base, but it is really your call Dan.
DW: amtu, is that a packet we are shipping. I'll pull that in then. wasn't
sure what we were deciding to do with it.
GW: steve, you wanted that enhanced for ipv6
SG: yes, DOD is switching soon I think. It didn't look hard. and it looked
like a matter of using unified address storage parameter instead of 32
bit location for ipv6 addresses.
GW: I agree, it looked simple
SG: I want to think Erlok Drepper(?) has some code to determine preferred
address for the machine. So the code doesn't even care.
GW: other things we need
IB: I have bugzilla query that is using a different way to find LSPP bugs,
I'll send it to you George and linda. Steve and Eric, this will give us
what we are looking for.
LK: there was some mail posted to lspp list about posix_msg_queue. it was a
question about if you can use them as system high. there is policy in
fs.te file. do people think it is a behavior people want to use if
enforced properly or is it a system high thing
GW: I think there was also question about what applications it would break
if it is at system high
LK: I'm wondering what is the correct behavior ought to be and if people
agree with that
GW: normally that wouldn't be mounted. so there is now policy that allows
everyone to mount it
LK: I don't know about that. so if it's not mounted then the msg-queues work
GW: you can access them through syscalls, but you can't use the filesystem
interface, at least that's what my understanding is.
LK: I need to do some more experimenting ..
GW: I think general answer is that you should use what mechanism is on
machine within policy
LK: I think it was related to how it was working at the time
GW: you can only mount at system high but make use of them at different
levels ... I think you can use them as to whatever your policy dictates.
I don't see any reason why they would only be restricted to system high
SG: Dan walsh and myself are going to be tied with meeting over next couple
of days, but will be back on Thursday.
GW: ok
SG: As for the symposium, I want to mention that the audit BOF was only one
registered, so they have open slots. Maybe we can get together and have
an informal talk ... I know steve you were interested in getting work to
have gov buy in
SG: yeah, there are other standards that we can consider ...
PM: If we are going to do a BOF about this, we might as well announce it so
that we can get customers and partners that don't attend this call, to
attend if they like.
SG: I'll see if we can schedule another session after the audit BOF
GW: point well taken Paul, it is a really good opportunity.
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
