12/04/2006 LSPP Meeting Minutes:
===============================
Attendees
George Wilson (IBM) - GW
Mike Thompson (IBM) - MT
Joy Latten (IBM) - JL
Matt Anderson (HP) - MA
Paul Moore (HP) - PM
Kylene Hall (IBM)
Bill O'Donnel (SGI) - BO
Kris Wilson (IBM)
Linda Knippers (HP) - LK
Klaus Weidner (atsec) - KW
Joe Nall - JN
Irena Boverman (RH) - IB
Steve Grubb (RH) - SG
Dan Walsh (RH) - DW
James Antill (RH) - JA
Lisa Smith (HP)
Eric Paris (RH) - EP
Please forgive if anything was omitted or anyone's name was not captured.
Kernel / Beta
=============
GW - Awaiting on virtual ethernet fix.
BO - Current status on ipsec on localhost?
JL - Currently broken, regular works, but labeled doesn't work. Not sure
why, will get back to it some time this week. Not seeing AVCs or
anything like that.
SG - Is there a bugzilla open for this?
JL - Nope, not yet. I would like a toggle to accept/reject unlabeled
packets. Have bugzillas opened against ipsec, people want to be
able to turn it off.
SG - OK, and a bugzilla is opened?
JL - Yes, want me to send note to lspp list w/ bugzilla number?
RHIT #108432
LK - Is normal ipsec broken on beta?
JL - It should be a config.
SG - It needs to default to old behaviour, loading policy should toggle
new behaviour.
GW - You might want to have it default old either way.
<fast conversation, lost content>
Discussion on labeled networking, recievefrom, etc. Sorry for the
lost minutes.
<end lost content>
JL - Ran labeled ipsec stress test w/ 56 kernel for ipv4 with audit,
etc. Will run ipv6 later tonight.
SELinux Base
============
KW - Still need to revisit constraints. Proposing single level object
and sockets for unprivileged users. Current system is not
LSPP-compliant (information flow). Can have an override that would
permit access to multi-level.
<discussion on the fallout from this>
LK - Has anyone got polyinstantition to work?
KW - Yes, it should be working. Need to do user creation in the right
order.
GW - I think Dan Walsh sent a note about that.
KW - Will try to do a step-by-step for a polyinstantiation HOWTO
LK - Can I see these with mount?
KW - Look in /proc/mount
LK - OK, with the new newrole, I can't newrole when polyinstantiation
fails.
MT - Yeah, that's intended, however, polyinstantiation shouldn't be
failing.
DW - Check the allow polyinstantiation boolean
MT - Whats the default value?
DW - Its off in targeted. Should it be on for strict?
MT - Yup, I'd think so.
KW - What about the pty problem?
GW - Fixed with levels selection right?
SG - Yeah, doing level selection now.
KW - With that change, do we still need polyinstantiation?
MT - Yeah, advanced features like looking at man pages will break
without.
LK - Can we sum that discussion up?
MT - To sum up: newrole off for non-admins, admins should have newrole
w/ polyinstantion working.
GW - And Level selection mech. required for normal users.
JA - pam selinux error, policy denies certain things. Did you get the
double-free bug fix?
KW - What pieces should we be using to test this? latest beta + ?
GW - Special pam package on James' page
SG - James, does rawhide have new pam package?
JA - Yeah, the guy who owns it said he got it and pushed it out.
KW - So current rawhide pam should let us test that.
KW - So no need to ship newrole as suid.
GW - Yeah, but we need level selection to work. Sent James and Dan a
table of things I have tried and complete it and get log messages
etc.
KW - Do people have a strong need for the xinetd level selection method?
JA - What do you mean by level selection? Had some patches that had a
config argument, but people didn't want that. Patch changed. Now,
it uses the current context of xinetd and incoming conn. to create
aggregate context, so no more config.
KW - Do people need that feature outside of ssh? If we want to support..
JA - Without that patch to xinetd, ftp services runs in unconfined.
KW - Yeah, we need that patch then. But none of the standard shipped
services should need it then. Wasn't ssh shipped standalone?
JA - Anything using network label switches will need patch I did for
xinetd. It takes level from context that comes in and takes
everything else from the current proicess (xintend) context and
generates the context of the new process.
KW - If you launch a not-label aware daemon, MLS constraints should
block the incoming packets... it might be useless, but not a
security concern. So your changes are needed if you need a USEFUL
multilevel services.
strict vs targeted
==================
GW - Linda asked why our base is strict, rather than targeted, and
doesn't that add additional complications? I think we went with
strict for the RBAC controls.
DW - All problems she's having are RBAC related. There is little
difference between strict and targeted other than RBAC.
KW - RBAC is very general, and doesn't specify what the roles are like
or who belongs. It would be possible to create a single all
powerful admin and having the users be broken into roles.
DW - If we want to change this, we can have a boolean that would make
sysadm super powerful.
LK - Worried about type enforcement on everything making type
enforcement hindering non-SELinux aware programs. I want unconfined
type enforcement, and only MLS enforcement.
DW - I've had a problem with understanding the read difference between
staff_t and user_t. And you are pointing out we have holes between
sysadm_t and secadm_t.
LK - Am worried about usability issues.
JA - useradd fix, if that goes in, sysadm_t is what useradd is running
at.
DW - Runs as useradd_t, so we can add privileges there.
KW - Its unfair to blame RBAC. RBAC says you need to be able to define
them, and then we had requirements coming in from users who would
be doing it, who wanted a separation between audit and sysadm, and
secondly sysadm and secadm. This is a requirement that kind of maps
to RBAC, but its not strictly a requirement.
LK - Is there a targeted MLS?
DW - No, there is only strict-mls and targeted-mcs
KW - We did have expectations from users to have a split between audit
and sysadm. So do we not need this split?
DW - Well, staff can run sudo, and user_t can't, so there is a sort of
split.
KW - That's not really what RBAC expects.
GW - So we would need to demonstrate separation of ordinary users and
hierarchies?
KW - Yes, but you would not need to be too extensive with hierarchies.
GW - So what would we need to do to demonstrate this?
KW - Need an example where you define roles and types. You would get
type enforcement involved, since that's the enforcement mechanism.
Users can then select from the roles they can access and show they
have different privilages.
DW - So my action item is to merge sysadm, secadm and auditadm?
KW - I'd be fine with that.
< Talk about this proposal >
DW - Let me see if we can do this wit a boolean.
JN - I vote for the boolean so the work gone into this isn't lost.
GW - I agree Joe. We still need to show the role seperation for normal
users?
KW - Yes.
GW - Yeah, we should open a bug to track that. I'll do this.
PAM
===
GW - Will try James's selection patches.
LK - One of the things I'm getting is strict doesn't get a lot of use
so we're hitting issues. Am worried about what we'll hit next. I
guess we can try it, and see what happens.
KW - Based on my understanding, if you have an unconfined_t without
overrides, you would end up with a MLS enforcement, but no RBAC. I
would hope you get similar behaviour with the user type. If we
aren't, then it might be too strict.
DW - I can do more investigation to try and find potential problems in
strict policy.
Labeled Networking
=================
GW - No outstanding CIPSO, issues. ipsec?
JL - Only outstanding item other than toggle is to finish policy so that
it will run in enforcing.
KW - Please feed policy to me for KS until it is upstream.
xinetd
======
GW - Any status on xinetd?
JA - With the fix Paul pointed out, it should be gtg.
Self tests / aide
=================
GW - Used call DW suggested, its working. Trying to get
read-up/write-down testing to work correctly. Will try to post
something this week, by thursday. aide seems to be working as
promised.
Cron, tmpwatch, mail, etc.
==========================
GW - Anyone try cron lately? got a complaint from one of our testers,
and asked him to open/reopen a bug.
Bugs / remaining tasks
======================
GW - For bugs we'll be following new process.
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
