[redhat-lspp] LSPP Development Telecon 01/16/2006 Minutes

George C. Wilson ltcgcw at us.ibm.com
Fri Jan 20 15:29:22 UTC 2006


I apologize for the delay in getting this out.

Known Attendees
---------------
  Lenny Bruzenak
  Tim Chavez
  Russell Coker
  Janak Desai
  Ken Hake
  Chad Hanson
  Darrel Goeddel
  Steve Grubb
  Debora Velarde
  Klaus Weidner
  George Wilson
  Kris Wilson
  Catherine Zhang

Labeled Networking
------------------
  CZ:  New hook for authorizing deletion of labeled data security association
    and policy.
  Instead of using relabelto and relabefrom, Trent decided to use setcontext
    authorization; this was a previous small patch that was applied.
  Will use same for deletion.
  Will send patch out for review today.
  Hopefully it will be posted tomorrow.
  Not much work on getpeersec().
  Using gmail for patches.
  Couldn't figure out how not to wrap patch from gmail.
  SG:  Will start including in test kernels.
  When it comes to LSPP list, will replace last version with that from list.

  GW:  What about Venkat's MLS enhancements?
  CH:  Venkat working w/current patches.
  Trying to get racoon support such that label ranges are authorized.
  Can work w/Joy to get into ipsec-tools.

VFS Polyinstantiation
---------------------
  JD:  Fixed oops.
  Completed writeup of justification and design.
  Sent that out.
  Unshare patches are back in.
  No comments on justification; so still not 100% sure if we will get resistance
    to inclusion into kernel.
  After ferment, will ask for inclusion.
  SG:  Also picked up for test kernel.
  JD:  SG also helped review and fix bugs in namespace module.
  SG:  Been reviewed for inclusion in main PAM package.
  Looking at lots of issues admins will run across.
  E.g., disk system not configured correctly and decide to polyinstantiate them;
    e.g., /home not a mountpoint.
  Login gets everything polyinstantiated, su to another account, and come back--
    it does umount of certain directories before su.  Not sure it remounts
    directories when you come back to original shell.
  JD:  Because su forks and sets up its own namespace, it should end up in
    original shell.
  Should end up in right shell; but needs to be tested for corner cases.
  SG:  Will continue to work with Janak to polish for inclusion.

Audit FS Completion
-------------------
  TC:  Code is there for path-based watch; but watches are not persistent.
  Couple of rhetorical questions to consider--some questions Amy may be asked
    when approaching fsdevel.
  E.g., devices.
  Only a couple of minor issues that I gave advice on.
  ~ 2/3 done.
  KH:  What is the backup plan if we need it?
  SG:  Not a point where RH thinks a backup plan is needed.
  We're at a point where we want to stay the course.
  TC:  Amy has been steadily releasing code.
  She appears to be on target.
  KH:  Just concerned about RH cutoff date.
  SG:  Even if all patches were done this week, it would take a month of
    politics to get it upstream.
  KH:  That's my point; we need to have it pretty soon if we want to meet the
    cutoff date.
  SG:  On IRC, Al Viro and several folks are reviewing FS patches.

Audit Enhancements
------------------
  SG:  Kernel/userpsace backwards compatibility is an issue.
  Trying to discuss with all parties.
  Have to have corresponding kernel and userspace.
  Will also have overlapping structs in kernel and userpace.
  Have no control over telling users which audit libs to use with which
    kernels.
  Need some backwards compatibility between old and new code depending on kernel
    version.
  KW:  Wouldn't failing sanely suffice?
  SG:  Other worry, other distros not on telecon, don't have knowledge of
    library and kernel versions.
  KW:  Auditd is fairly tied to kernel.  Another example is modutils.
  SG:  I see the point, but would have to maintain lots of compatibility cruft.
  RC:  Not much hope of getting audit in Debian; recompile everything in gentoo.
  Not like LVM where it won't boot; with audit it will come up and you have to
    fix.
  GW:  So we don't care all that much about compatibility?
  RC:  It's a tradeoff.
 
  GW:  Any other audit news? 
  SG:  Dustin still trying to get stuff in and out of kernel.
  Have to update both userspace and kernel. 
  Test kernel oops'd immediately.

Audit Boot Messages
-------------------
  SG:  Rawhide system puts boot stuff in syslog.
  See AVC message in syslog.
  Would expect them in audit log.
  How long to save to save them before giving up on audit daemon and routing to
    syslog?
  Gets kicked off by rc.sysinit.
  Only way to send an audit message would be through auditctl.
  Will get to in a couple of weeks; working namespace module now; needs to get
    into something we can test.

Audit of Networking
-------------------
  GW:  Need to make sure we cover audit of network events.
  SG:  May be covered already.
  May be worthwhile to analyze audit system as is to see if it is enough.
  Also brings question about ioctls.
  User program shouldn't be able to change labels.
  ioctls() and setsockopt(), audit by connection, audit by address.
  RC:  Netfilter and audit?
  SG:  Would want one config file for info for auditing.
  RC:  If we were hooked in w/netfilter, probably has to go through iptables
    rather than audit rules.
  SG:  Already had this discussion for SELinux rules.

Audit API
---------
  SG:  Willing to get together with a couple of folks and start working API
    soon.
  Contacted folks at Mitre.
  Have polgen that analyzes audit logs.
  So they have some perspective as an audit consumer.
  Should have opinions on what interface should do.
  DV:  What about design proposal document we sent?
  SG:  Replied directly to you on that.
  Want to aim API toward tool writers.
  Need to support high-level languages, like python.
  Want input from python folks to properly spec out API.
  Want all stakeholders to be involved.
  Real API will be in C; but want to ensure data structs are easy for python
    folks.
  GW:  So are Mitre folks willing to help?
  Mitre seems ready and willing to help.
  Let namespace PAM modules get done first.

Binary Records
--------------
  GW:  Tim has looked at XDR.
  SG:  Not needed for LSPP.
  Doesn't have to be done at same time as API.
  Not sure all record formats are already done; probably other things as well.
  Things are not static enough yet to move to binary.

  SG:  One of concerns is performance of audit system.
  Discussed w/David about not attempting to create audit contexts if not used.
  Impact would be, whenever there is an SELinux even, won't get full syscall
    associated with it.
  Asked if could have partial syscall record for context; won't have chance to
    grab args; many data we do have available; would be a record format change.

  TC:  Xdr would require lots of work.
  What is value of binary record?
  SG:  Would be to avoid parsing issues and save space.
  TC:  Does it outweigh cost of development?
  
Cron
----
  JD:  Starting on Stephen's comments on cron.
  Will send to LSPP and cron maintainers.
  GW:  What about at and tmpwatch?
  JD:  Leave them on the list for now; will look at after cron.

  SG:  At and anacron will be cron wrappers.
  Cron will be doing everything.
  GW:  So we get at for free?
  SG:  Unclear.

Self-Test
---------
  GW:  Posted TSOL Security Target self-test statement.
  Don't help us much.
  So we're going to need some sort of integrity verification, perhaps tripwire.
  SG:  RH stopped shipping tripwire.
  Would need to teach about prelink and xattrs.
  We all need to learn more about prelink; not well documented.
  Xattrs are well documented.
  KW:  Tripwire may be too heavyweight; but it may the most efficient way to
    implement it.
  SG:  Mandrake security tool may be adapted as well.
  RC:  Might look at sxid from Debian as well.
  KW:  Prelink itself can tell you if a binary has been modified by something
    besides prelink.
  RC:  Only helps in finds accidental damage, not malicious damage.
  KW:  Intention of RBACPP is to check that nothing was corrupted, not IDS.
  SG:  Not protected from malicious admins.
  KW:  It is questionable that for that particular requirement additional
    security is added.
  RC:  RPM -v wouldn't work because there are non-rpm files we want to check.
  KW:  Fail to secure state if corrupted; goal it to end up in secure state, not
    fullblown IDS.

  SG:  Checksums of binary policy files?
  Stephen said creating checksum would be easy if there is a requirement.
  Need to follow up on that work to see if is should be done.
  Ask Stephen.

Device Allocator
----------------
  CH:  Dan and Paul at least compiled it.
  There was discussion of pulling into RPM at one time--mlsutils.

-- 
George Wilson <ltcgcw at us.ibm.com>
IBM Linux Technology Center




More information about the redhat-lspp mailing list