[redhat-lspp] LSPP Development Telecon 10/12/2005 Minutes

[George Wilson]

Debora Velarde prepared the notes below with minor edits from me.

------------------------
LSPP Meeting 10/12/2005
------------------------
Known Attendees:
        Matt Anderson (HP)
        Andrius Benokraitis (Red Hat)
        Tim Chavez (IBM)
        Darrel Goeddel (TCS)
        Amy Griffins (HP)
        Steve Grubb (Red Hat)
        Ken Hake (IBM)
        Chad Hanson (TCS)
        Trent Jaeger (PSU)
        Dustin Kirkland (IBM)
        Linda Knippers (HP)
        Emily Ratliff (IBM)
        Chad Sellers (Tresys)
        Stephen Smalley (NSA)
        Debora Velarde (IBM)
        Klaus Weidner (atsec)
        George Wilson (IBM)
        Kris Wilson (IBM)

Tentative Agenda:
        Welcome
        Increasing meeting frequency
        Tasks and assignments
        Device allocation design
        Testing
        Status

----------------------------------------------
Steve, George, and Klaus coming to some convergence; working to come to
complete convergence.
Goal is to make this a status taking meeting.
Hope to take status of each of the items to see where we are, where we are
making progress, where we're not.

--------------
IPsec labels
--------------
- Revising patch to deal with caching of flow objects correctly.
- Case with server that can receive packets from hosts with different
labels.
        Code doesn't take into account the label of the packet it receives.
        Only looks at the policy.
- Need to make Herbert Xu aware of the issue.
- Trent hoping to have something by end of week or so.
- Catherine is in the loop (but not on call).

- getsockopt()
  TCP - we're close to OK.
  UDP
     - Could tunnel UDP, but then do you have properly labelled packets?
     - Don't have place to pass label along right?
     - Quick dirty solution is to see the label of the last packet you
received was.
     - Could be Joy and/or George that could fill up that gap.
     - Trent was thinking of starting Catherine on that.

----------------------------------
Builds, repos, and other logistics
----------------------------------
- Increasing frequency of meeting back to once a week.
  ACTION: George to send out new meeting notice.

- Task list will be unified list used to track progress.

- Russell Cooker may be able to set up a wiki for us.
- Russell has also offered to set up a test system.

- Yum repo
  Kernel is probably the only thing that we need to keep separate from
rawhide.
  For most patches (other than kernel), when ready, RH will review it and
then apply it to rawhide.
  Don't really have patches to kernel yet.

- Wiki could be used to have all available documentation in one spot.
  Some documentation posted on SELinux mailing list.
  Step-by-step instructions for setting up MLS system to be posted on LSPP
list.
  Need similar instructions for setting up networking hooks.
  ACTION: Joy to send out documentation for networking hooks setup.
  Until we have a wiki, need to post documentation to the list with subject
"Document" or "HOWTO."
  Should also include version number.

----
Misc
----
- pSeries can't boot rawhide right now (been for a number of weeks).
  ACTION: George to open bug report in bugzilla and send the bug number to
Steve.

-----
Audit
-----
Steve Grubb - Past week working on audit report and email alert (when
running out of space).
- Plans to finish that up this week.
- Then open 1.1 audit branch to start collecting patches to start LSPP work
by end of week.
- Other big issue is someone discovered memory leak - patch posted to
mailing list.

Dustin posted patch for subject and object labels.
- Got feedback from Chris Wright (not on phone), trying to get a hold of
him on IRC.
- Chris' feedback should represent some of the things discussed by multiple
folks on IRC.

Filter - exclude list
- Ability to filter by message type.
- Audit msg number block sparsely numbered (for performance; faster
compares).
- Doesn't fit a bitmask easily:
  Would require translation layer (overhead).
  If renumber, then it doesn't allow for quick kernel comparison.
  Userspace tools already relying on these number and SELinux also.

The implementation Dustin's been working on:
- Is a linked list.
- Pairs of numbers representing a range.
- For a point those 2 #s are the same.
- Gives infinite flexibility of what can be included/excluded.
- Performance benefit if we order that list, easy to cycle that list.
- Goal of increasing the types of operators for writing rules, ex: <, >,
range.
  Need to be able to give it a range, first thing where we need to be able
to pass 2 values for 1 field.
- Could use the same mechanism for passing data to kernel.

HP doesn't think they are related.
- Amy doesn't agree with design.
- Amy thinks the code to do that is already in place.
- Amy doesn't think the concept of suppressing a range from 1200 to 1310
would be clear.
  Would make more sense to the admin if there was a particular related
group (syscall, login).
- Dustin: It doesn't make so much sense in the type field but makes more
sense for other fields like UID.

Suppressing msg types
- Would have pre-canned values that makes sense.
- Worried about arbitrary values. What could those point to?
- Admins shouldn't be using the raw numbers.
- But ranges only make sense if you do know the raw numbers.
- Could force users to upgrade userspace (RHEL4 to RHEL5).
- They may have different kernels in a dual boot.

Why can't it be a bitmask?
- Doesn't map to bitmap since the numbers are sparse.
- Would need translation table.

What about audit log start passing # and group #?
- Loose flexibility.
- Amy: That flexibility not really necessary.
- Linda: Admin would want flexibility .

Amy doesn't think it makes sense to reuse the code.

Discussion to continue on mailing list.

--------
audit_fs
--------
Tim's status:
- Added support for multiple filter tags.
- One deadlock on removal of watch.
- ETA for alpha code next week (includes code comments and initial stress
testing).

Tim still needs to:
- Fix deadlock.
- Write design documentation.
- Perform FVT testing, more comprehensive stress testing.
- Do performance testing.
- Converge with audit-inode-catchalls patch.

Tim's build info:
- 2.6.13
- 2.6.13-rc6-mm2
- inotify-kernel-api
- inotifiy-name-to-dentry
- audit client
* Missing audit-inode-catchalls patch.
      Need to augment patch to grab inode audit filters.


Amy's Status:
- Did some testing these past couple days and found some bugs.
- One more piece to test and will pass that on to Tim.

---------------------
VFS polyinstantiation
---------------------
Polyinstantiated directories:
- Steve and Linda talking about polyinstantiated directories.
- Steve thinks not a big problem for audit, but might be for inotify
because might get info from diff levels.
- Audit should be running at high - should see everything.
- Access to the audit log is restricted.
- 3rd party SW having access to stuff it shouldn't.
Klaus: Config guide tells admin to not do those things.
Steve Grubb: Trying to make a useful system.
- Different flavors of root based on role: security admin root or system
admin root.
Klaus: This is but one example of a more general issue.
  The reason why we are making restrictions: can't make statements about
stuff you haven't looked at.
Klaus: Would be good to fix inotify so it avoid covert channels but think
this is a side issue.
- Lots of things could break if don't have polyinstantiated directories.
Linda: If you set a watch on a polyinstantiated directory, is the right
thing going to happen?
What directories are going to be polyinstantiated?
      /home, /tmp, but configurable so it could be anything.
Requires more thought - to be continued on the list.

-----------------
Auditing of roles
-----------------
Context represented as sids that are not bit fields.
How do you efficiently extract info?
Is there an efficient way?

1. Compiling policy and installing policy.
2. More direct through audit way.

Separation of duties
- No problems with audit system adding rules but should it directly
manipulate AVC records through audit (traditionally done thru policy)?
- Should audit kernel interface configure or defer enable/disable to
security subsystem.
- Are you just duplicating functionality already in security subsystem?
- Common front end?

--end of meeting--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/redhat-lspp/attachments/20051014/bce15591/attachment.htm>