From ltcgcw at us.ibm.com Sat Oct 1 16:51:34 2005 From: ltcgcw at us.ibm.com (George Wilson) Date: Sat, 1 Oct 2005 11:51:34 -0500 Subject: [redhat-lspp] LSPP Development Telecon 09/28/2005 Minutes Message-ID: <20051001165134.GA21982@us.ibm.com> Following are minutes from the Sept. 28 LSPP development telecon. They were produced by Debora Velarde with minor edits from me. ----------------------------------- LSPP Development Telecon 09/28/2005 ----------------------------------- Known Attendees: Matt Anderson (HP) Andrius Benokraitis (Red Hat) Mounir Bsaibes (IBM) Tim Chavez (IBM) Russell Coker (Red Hat) Janak Desai (IBM) Darrel Goeddel (TCS) Steve Grubb (Red Hat) Ken Hake (IBM) Chad Hanson (TCS) Trent Jaeger (PSU) Dan Jones (IBM) Linda Knippers (HP) Joy Latten (IBM) Paul Moore (HP) Emily Ratliff (IBM) Stephen Smalley (NSA) Michael Thompson (IBM) Debora Velarde (IBM) George Wilson (IBM) Catherine Xiaolan Zhang (IBM) Tentative Agenda: Welcome and ground rules Audit IPsec labels VFS polyinstantiation Device allocation design Builds and repos Testing Tasks and assignments ----------------------------------- Trent's IPsec Labeling Patch Status ----------------------------------- Trent's status first since he needs to drop off. Made another submission to netdev. Herbert Xu has an issue. Trent delegated it to Catherine. She made a proposal. The issue: cache of flow objects and you can use these rather than reauthorizing when you are looking to find the connection you are going to use with the remote party. Need to authorize this based on IPsec networking controls. Sometimes use IPsec, sometimes may need to use IPsec, need to take care of all combinations. Need to enumerate all combinations and make sure all are taken care of. IBM and TCS doing some testing. Venkat from TCS also looking at extending nethooks to accommodate MLS. ETA for when it will go upstream? Getting close. Have gone thru xfrm user interface in detail. xfrm interface shouldn't slow us down; Trent not aware of anything that uses it. pf_key looks fine. David Miller will revise that part of the code. Steve Grubb: UDP question on mailing list? Getting the label from a UDP socket where you don't really have a connection at all. Idea that there would be a race condition between getting the packet and determining it's label. Application is making the decision; it should have some control over it's socket to ask what the last label was that it received the label for, but not sure how reliable that is. Needs to be looked at in more detail looking for a number of race conditions. ----- Audit ----- Steve Grubb just started working on audit code again. Was working on getting statistical analysis programs working Summary info about what is in the log. Ausearch will find you stuff. But people will want more analytical tools. Steve updated ausearch, can now search on context. Auditing of roles, still undecided on approach to take. Still have some issues there before doing a lot of coding else will have to rewrite a lot. Linda: you have some ideas of how the work can be split up going forward? Inotify integration - Other areas help needed: Dustin has tackled auditing by type. Way of auditing key usage (key infrastructure in the kernel) could use it as a covert channel. Need to put in auditing hooks so we could see what's going on. Couldn't we limit to admin for now? Keyring folks are working on this. 1. David Howells doing the labelling. 2. May need to add hooks. May need to audit based on the key used. Key could have multiple compartments. Steve will ask him about what the time frame is, include it or exclude it. Tim's status: Amy sent him a patch before she left. On every syscall that accesses object, want a record of that access. Adds ability to filter on syscall, filesystem access. Need to find places in kernel where we could put that. Audit tag in the inode. Audit client - finishing up everything except the main logic. Interface kernel -> user and user -> kernel. Plugged into API that Amy wrote. Should be able to get alpha code out late this week or early next week. Tim hasn't tried Amy's patch yet, but will put it into his patch set and try it. -------------- Builds & Repos -------------- IBM thinking of creating an internal yum repository so we can look at our changes in context of recent rawhide build. Do you see any value of us doing our own? The issue with IBM creating a yum repo would be with trying to make it public. Red Hat would probably have an easier time doing that than we would. David not on call. Need to have a somewhat stable build to work on. Not sure who could do it right at this minute, Red Hat in the middle of re-organizing and re-assigning people. May be next week before we know who is going to be involved in this. If David is not able to help us, Andrius can. What would be on the repository? The kernel. A lot other pkgs could be safe. One repository for all the LSPP kernel changes, or different ones? For example one with audit changes, another with networking. Really want something semi-stable. Want to use most of rawhide but the kernel; want to do ours. Would it speed up productivity if developer could push changes themselves? Problem is it has to go thru build farm. With previous audit group, changes and patches sent to the group and then rolled up; put a dependency on David. Need central place with multiple people at Red Hat having access to push changes. When we pick a rawhide build, would we take a snapshot, use that, and periodically rebase? What would be the criteria for rebasing? Need a rolling update, composing on top of rawhide (every 10 days). We can't get too behind rawhide (really close to what is upstream except with extra packages) Every 2 weeks or whenever warranted. The kernel is the main package we need to turn around. Only issue with rawhide it is a 24 hour turn around. ----------------- Polyinstantiation ----------------- Janak has a patch that is reworked based on feedback from Chris Wright. Chris caught problems with synchronization and memory leaks. Janak gave feedback to Ram by who is doing the shared work. Overlaps some of the namespace work. Hopefully this week Janak will send that out based on the latest mm tree. Update on cron? Cron not going to be using polyinstantiated directories. Janak will work on cron once he's done with unshare. Other polyinstantiated/MLS features like tmpwatch and slocate? Others not needed for LSPP, but nice-to-have items. Shouldn't be too much work to get them to work. Janak volunteered. ------------------------ Device Allocation Design ------------------------ George became convinced we need this. So we don't have users chcon'ing things themselves or auto-relabelling udev. Wanted Dan Walsh's thoughts on that. George will bring it up on the mailing list. Paul Moore need some tools and libraries for device allocation. Did work to flush out work initially done by TCS. Sitting on a patch, waiting on license from TCS, sitting in legal now. ----- Print ----- CUPS patch: 2 existing CUPS patches: 1. TCS work. 2. Auditing done by HP. CUPS people getting ready to drop major release. Matt working on another patch to do all of the interprocess communication over af_unix. Then can show all 3 patches. Suggested that Matt post patches on LSPP list. Matt will post it to LSPP list soon. ------- Testing ------- Joy has put together some MLS tests. We've reviewed internally before posting. Joy also incorporated Steven's base SELinux tests into LTP. Still need help in increasing the coverage. Linda is looking into test work HP would be interested in. IBM direction internally is to create functional tests for whatever we write and incorporate that into LTP. If you generate code, then you should produce the testcases as well. Testing isn't focus, development is. Plan is to expand the LTP. Some items may not be appropriate for LTP, but many things are. ------------------- Tasks & Assignments ------------------- Folks can volunteer for assignments or we can divvy the work. Task list is a starting point. People are encouraged to volunteer for items. If you are in a lead position, please help divvy up work. Task list--can beat it up, augment it, etc. Please help take ownership of the items. ---------------- Additional items ---------------- Joint Red Hat, TCS, IBM announcement. Around the room, introductions. -- George Wilson IBM Linux Technology Center From rcoker at redhat.com Tue Oct 4 02:11:57 2005 From: rcoker at redhat.com (Russell Coker) Date: Tue, 04 Oct 2005 12:11:57 +1000 Subject: [redhat-lspp] LSPP Development Telecon 09/28/2005 Minutes In-Reply-To: <20051001165134.GA21982@us.ibm.com> References: <20051001165134.GA21982@us.ibm.com> Message-ID: <1128391918.3103.7.camel@aeon> On Sat, 2005-10-01 at 11:51 -0500, George Wilson wrote: > IBM thinking of creating an internal yum repository so we can look at > our > changes in context of recent rawhide build. > Do you see any value of us doing our own? > The issue with IBM creating a yum repo would be with trying to make it > public. > Red Hat would probably have an easier time doing that than we would. Making a public repository as an official Red Hat thing will take some effort. However many of us have servers that can do the job. It would be quite easy for me to setup a web server on one of the machines I administer and give ssh/scp accounts to everyone who wants it. I still doubt the utility of this but I'm willing to run it if that will help get things moving. Anyone who is interested can send me a ssh public key and a preferred account name. From jmorris at redhat.com Tue Oct 4 04:26:33 2005 From: jmorris at redhat.com (James Morris) Date: Tue, 4 Oct 2005 00:26:33 -0400 (EDT) Subject: [redhat-lspp] LSPP Development Telecon 09/28/2005 Minutes In-Reply-To: <1128391918.3103.7.camel@aeon> References: <20051001165134.GA21982@us.ibm.com> <1128391918.3103.7.camel@aeon> Message-ID: On Tue, 4 Oct 2005, Russell Coker wrote: > On Sat, 2005-10-01 at 11:51 -0500, George Wilson wrote: > > IBM thinking of creating an internal yum repository so we can look at > > our > > changes in context of recent rawhide build. > > Do you see any value of us doing our own? > > The issue with IBM creating a yum repo would be with trying to make it > > public. > > Red Hat would probably have an easier time doing that than we would. > > Making a public repository as an official Red Hat thing will take some > effort. > > However many of us have servers that can do the job. It would be quite > easy for me to setup a web server on one of the machines I administer > and give ssh/scp accounts to everyone who wants it. > > I still doubt the utility of this but I'm willing to run it if that will > help get things moving. > > Anyone who is interested can send me a ssh public key and a preferred > account name. I think Dan Walsh can pretty easily just set up a repo via his ftp site, and was intending to do so. - James -- James Morris From linda.knippers at hp.com Tue Oct 4 16:29:28 2005 From: linda.knippers at hp.com (Linda Knippers) Date: Tue, 04 Oct 2005 12:29:28 -0400 Subject: [redhat-lspp] File Integrity Tests from RBAC In-Reply-To: <200509291403.36799.sgrubb@redhat.com> References: <200509291403.36799.sgrubb@redhat.com> Message-ID: <4342ADE8.9000504@hp.com> Steve Grubb wrote: > Hello, > > I was wondering how we were planning to address these items in the RBAC specs: > > >>FPT_TST.1.2 The TSF shall provide authorised users with the capability to >>verify the integrity of TSF data. > > >>FPT_TST.1.3 The TSF shall provide authorised users with the capability to >>verify the integrity of stored TSF executable code. > > > Is this traditionally done with something like tripwire? What other solutions > do we have to this? If we use rpm --verify, it is likely to complain about > all the chmods that were done to meet the security target. If there's a configuration script for LSPP similar to the one for CAPP, this sounds like something you'd want that script to be able to do since it knows how the various files are supposed to be configured and what the permissions are supposed to be. -- ljk From sgrubb at redhat.com Tue Oct 4 16:50:07 2005 From: sgrubb at redhat.com (Steve Grubb) Date: Tue, 4 Oct 2005 12:50:07 -0400 Subject: [redhat-lspp] File Integrity Tests from RBAC In-Reply-To: <4342ADE8.9000504@hp.com> References: <200509291403.36799.sgrubb@redhat.com> <4342ADE8.9000504@hp.com> Message-ID: <200510041250.07500.sgrubb@redhat.com> On Tuesday 04 October 2005 12:29, Linda Knippers wrote: > If there's a configuration script for LSPP similar to the one for CAPP, > this sounds like something you'd want that script to be able to do since > it knows how the various files are supposed to be configured and what > the permissions are supposed to be. I'll agree that it should know the files and permissions, but will it know the labels and the contents of the config files? Also, does it need to ensure that the version of the executable hasn't been altered? And how does upgrades work? If there is a software update to fix a security problem, is the Integrity test suite now broken? -Steve From sgrubb at redhat.com Tue Oct 4 17:08:15 2005 From: sgrubb at redhat.com (Steve Grubb) Date: Tue, 4 Oct 2005 13:08:15 -0400 Subject: [redhat-lspp] audit messages CAPP vs LSPP Message-ID: <200510041308.15612.sgrubb@redhat.com> Hello, I was looking at the audit requirements. We need LSPP to coexist with CAPP. Should the user space utilities send LSPP context information all the time and let the kernel strip it out...or should there be a mode variable somewhere that it can look at to decide if CAPP or LSPP information should be sent? -Steve From linda.knippers at hp.com Tue Oct 4 17:20:15 2005 From: linda.knippers at hp.com (Linda Knippers) Date: Tue, 04 Oct 2005 13:20:15 -0400 Subject: [redhat-lspp] File Integrity Tests from RBAC In-Reply-To: <200510041250.07500.sgrubb@redhat.com> References: <200509291403.36799.sgrubb@redhat.com> <4342ADE8.9000504@hp.com> <200510041250.07500.sgrubb@redhat.com> Message-ID: <4342B9CF.4090302@hp.com> Steve Grubb wrote: > On Tuesday 04 October 2005 12:29, Linda Knippers wrote: > I'll agree that it should know the files and permissions, but will it > know the labels and the contents of the config files? If the labels and the contents of the config files matter (and they would, wouldn't they?), then the configuration script would be verify or set the information at configuration time and then be able to verify it later. > Also, does it need to ensure that the version of the executable > hasn't been altered? To meet FPT_TST.1.3, it probably would. > And how does upgrades work? If there is a software update to fix a > security problem, is the Integrity test suite now broken? If only authorized users can install software, including security updates, then the script could check that the software still matches what was installed, either at configuration time or with an update, and still has the appropriate permissions and labels as required for the LSPP configuration. If the configuration script is changing permissions or labels, then you'd probably want to re-run it after any update in case the update reset anything that the configuration script changed. -- ljk From mcthomps at us.ibm.com Tue Oct 4 18:23:06 2005 From: mcthomps at us.ibm.com (Michael C Thompson) Date: Tue, 4 Oct 2005 13:23:06 -0500 Subject: [redhat-lspp] audit messages CAPP vs LSPP In-Reply-To: <200510041308.15612.sgrubb@redhat.com> Message-ID: > I was looking at the audit requirements. We need LSPP to coexist with CAPP. > Should the user space utilities send LSPP context information all the time > and let the kernel strip it out...or should there be a mode variable > somewhere that it can look at to decide if CAPP or LSPP information should be > sent? As I understand it, adding LSPP on top of CAPP won't detract from CAPP, so is there any harm in just always collecting LSPP information? I guess I am trying to understand why you would want to strip LSPP / switch between them? - Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgrubb at redhat.com Tue Oct 4 18:31:00 2005 From: sgrubb at redhat.com (Steve Grubb) Date: Tue, 4 Oct 2005 14:31:00 -0400 Subject: [redhat-lspp] audit messages CAPP vs LSPP In-Reply-To: References: Message-ID: <200510041431.00555.sgrubb@redhat.com> On Tuesday 04 October 2005 14:23, Michael C Thompson wrote: > As I understand it, adding LSPP on top of CAPP won't detract from CAPP, so > is there any harm in just always collecting LSPP information? There is additional overhead of processing more data, more data to sift through on disk, and wasted disk space if its not needed. I am trying to do what I can to preserve disk space and keep performance high. -Steve From mcthomps at us.ibm.com Tue Oct 4 18:43:07 2005 From: mcthomps at us.ibm.com (Michael C Thompson) Date: Tue, 4 Oct 2005 13:43:07 -0500 Subject: [redhat-lspp] audit messages CAPP vs LSPP In-Reply-To: <200510041431.00555.sgrubb@redhat.com> Message-ID: > On Tuesday 04 October 2005 14:23, Michael C Thompson wrote: > > As I understand it, adding LSPP on top of CAPP won't detract from CAPP, so > > is there any harm in just always collecting LSPP information? > > There is additional overhead of processing more data, more data to sift > through on disk, and wasted disk space if its not needed. I am trying to do > what I can to preserve disk space and keep performance high. I would imagine its faster to be stripping the extra information out before you shift it to userspace, as opposed to the mode variable, unless the mode will not be changing frequently. The drawback with a mode will be the testing penalty you incure each time you pass through it. I would say that keeping performance high out weighs any disk-space concerns, so that if it turns out to be too much of a it on the stripping, it would be easily bypassed, as opposed to going through and taking out extra tests. - Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgrubb at redhat.com Tue Oct 4 21:46:52 2005 From: sgrubb at redhat.com (Steve Grubb) Date: Tue, 4 Oct 2005 17:46:52 -0400 Subject: [redhat-lspp] LSPP work items Message-ID: <200510041746.52600.sgrubb@redhat.com> Hello, I have finished reviewing specs and have pulled together a sheet that has a number of work items in it. The list still needs vetting. I have labeled the items to show where they come from. I put R for RBAC and L for LSPP and then the section it came from. Some things are not in the specs, like 3.1, 3.11, or 3.12. But I think these are items that we want coverage on to make sure the system is solid. If there are no parenthesis, I did not find it in the specs. An example of this would be file system polyinstantiation. Please let me know if something is missing or doesn't look right. -Steve ================ 1. Basic 1.1 Objects shall include: files, named pipes (fifo), sockets, devices, shared memory, message queue, semaphores. New object: kernel keys 1.2 There shall at least 16 levels of hierachial labels and 64 compartments(L/FDP_IFF.2.7) however, we should have 256 compartments 1.3 RBAC access control is modeled on DAC (need clarification?). Users shall have right to set restrictions on their Objects (R/FMT_SMR.2) 2 Audit User Space 2.1 Events shall contain unique session identifier and/or terminal (R/FAU_SAR.1) 2.2 The ability to search on subject and object labels (L/FAU_SEL.1) 2.3 The ability to search based on type of access and role that enabled access (R/FAU_SAR.3) 2.4 The ability to search based on subject and object role (R/FAU_SAR.1) 2.5 There shall be a method to audit based on keys 2.6 There shall be a way to audit based on network address 3 Kernel - Audit related 3.1 Create new audit record types for: rlimit violations, lspp subject, lspp object, crypto, anomolies, and response to anomolies. 3.2 All Subjects and Objects shall be labeled - Network and kernel keys needed (L/FAU_GEN.1) 3.3 Subject & Object information must be labeled in events (L/FAU_SAR.3) 3.4 Role must be identified in events (R/FAU_GEN.1) 3.5 For access control actions, the role that made access possible has to be recorded. (R/FAU_GEN.1) 3.6 Audit events shall contain unique session identifier and/or terminal(R/FAU_SAR.1) 3.7 Audit events can be filtered by Object or Subject labels (L/FAU_SEL.1) 3.8 Audit events can be filtered by host identity, event type, users belonging to certain role, and access types. (R/FAU_SEL.1) 3.9 There shall be a method to audit based on keys 3.10 There shall be a way to audit based on network address 3.11 Loading MAC policy is auditable event 3.12 Changing policy booleans is auditable event 3.13 Service discontinuity is auditable event. (R/FPT_RCV.1) 3.14 When user space message is relayed, add a subject message to same event(L/FAU_GEN.1) 4 Kernel - MAC related 4.1 MAC policy shall allow what's specified by LSPP 4.2 All actions performed by MAC policy can be audited - grant or denied 4.3 When role data base is offline, corrupt, or unaccessable, the system shall preserve a secure state (R/FPT_FLS.1) 4.4 RBAC stipulates that after a failure or service discontinuity, the machine shall enter a maintenance mode whereby the machine can be restored to a secure state. Maybe config param for rc.sysinit (R/FPT_RCV.1) 5 Kernel Export/Import of Data 5.1 Export of Data (FDP_ETC) 5.1.1 Export is controlled by MAC policy 5.1.2 unlabeled data stays unlabeled 5.1.3 labeled data stays labeled 5.1.4 unlabeled devices cannot be used to export data unless a change of state is performed manually and it is audited 5.1.5 security mechanisms must be provided to the data that are exported by devices to media that do not have labels with the actual data 5.1.6 Hard Copy 5.1.6.1 hard copy data must be labeled on every page (FDP_ETC) 5.1.6.2 admin shall be able to specify label associated with the data. Overrides are an auditable event. (FDP_ETC) 5.1.6.3 each print job will have label on header page representing the "least upper bound" of the whole print job 5.1.6.4 each page will have the label representing the "least upper bound" of all data exported 5.2 Import of data (FDP_ITC) 5.2.1 Import is controlled by MAC policy 5.2.2 shall ignore security attributes associated with unlabled user data 5.2.3 devices used to import data without labels cannot do so if previously allocated to importing data with labels without a manual state change that is auditable 5.2.4 system must provide protection mechanism for data imported from unlabeled sources. 5.2.5 attributes from the user data will be retained when labeled 6 File System Poly-instantiation 6.1 We need to have this to make life easier 7 User RBAC utilities 7.1 User shall have the ability to see list of authorized Roles (R/FIA_ATD.1) 7.2 User shall have the ability to see any user attribute related to Roles (R/FIA_ATD.1) 7.3 User shall have the ability to change to any authorized Roles (R/FMT_SMR.2) 7.4 Access granting functions shall fail when policy or role database is inaccessable. (R/FPT_RCV.4) 8 User Space SE Linux 8.1 Admin shall be able to customize compartment names 8.2 All utilities that display contexts shall be updated to display compartments. They shall display the custom name. 8.3 Admin shall be able to assign roles to users (R/FMT_MSA.1) 8.4 Given a file, the Admin shall be able to determine who can access it 8.5 Standard MAC policy needs creating 8.6 newrole made into suid program so that it can send audit messages 8.7 assignment of user to role/se linux user is auditable. (R/FAU_GEN.1) 9 Device Allocator 9.1 Handles authorization of access to the device, 9.2 Handles synchronization of access to the device, 9.3 Determines the context to assign to the device node dynamically based on the allocating process, 9.4 Handles related operations like eject/close as part of the allocation/unallocation so that the relabeling is synchronized with the insertion of particular media. 10 Self Test 10.1 RBAC requires that a suite of tests be available that demonstrates that the machine is correctly operating. (R/FPT_TST.1) 10.2 Authorized users shall also be able to verify the integrity of data and executables called out in security target. (R/FPT_TST.1) 10.3 Tests shall produce audit records indicating that it was run and any failures. (R/FPT_TST.1) 11.0 Postfix 11.1 Add loginuid code to set it when delivering local mail (L/FIA_USB.1) 12.0 Procmail 12.1 Add loginuid code to set it when delivering local mail (L/FIA_USB.1) 13.0 Udev 13.1 No hotplug events shall label devices. It can only make sure they are unlabeled. (L/FDP_ETC, FDP_ITC) 14.0 initscripts 14.1 Shutdown needs hwclock call moved to before killing the audit daemon (L/FPT_STM.1) 15 cron 15.1 Multi-level cron 16 xinetd 16.1 Multi-level inetd is needed 17 Shadow-utils 17.1 update shadow-utils to insert object information in the messages (L/FAU_GEN.1) 18 util-linux 18.1 hwclock needs update for contexts (L/FAU_GEN.1) 18.2 login needs contexts update (L/FAU_GEN.1) 19 pam 19.1 various updates for labels 20 passwd 20.1 update to insert object information in the messages (L/FAU_GEN.1) 21 Turing Complete Programs 21.1 Review all Turing complete programs to see if they need augmentation: sed, awk, rpm, bash, tcsh, perl, python, postscript, m4, cpp From jmorris at redhat.com Wed Oct 5 03:11:00 2005 From: jmorris at redhat.com (James Morris) Date: Tue, 4 Oct 2005 23:11:00 -0400 (EDT) Subject: [redhat-lspp] LSPP work items In-Reply-To: <200510041746.52600.sgrubb@redhat.com> References: <200510041746.52600.sgrubb@redhat.com> Message-ID: On Tue, 4 Oct 2005, Steve Grubb wrote: > 3 Kernel - Audit related > 3.1 Create new audit record types for: rlimit violations, lspp subject, lspp > object, crypto, anomolies, and response to anomolies. What do you mean by crypto here? > 4.3 When role data base is offline, corrupt, or unaccessable, the system shall > preserve a secure state (R/FPT_FLS.1) What exactly does corrupt mean here: invalid file format or valid file format with incorrect data? > 5 Kernel Export/Import of Data > 5.1 Export of Data (FDP_ETC) > 5.1.1 Export is controlled by MAC policy > 5.1.2 unlabeled data stays unlabeled All data is labeled under SELinux in the kernel, but not necessarily persistently. e.g. if you context mount an unlabeled partition, the entire partition will be labeled while mounted but no labels will be written to disk. > 5.1.5 security mechanisms must be provided to the data that are exported by > devices to media that do not have labels with the actual data What does this mean? Being able to differentiate access in policy based on the labeling behavior of the device? SELinux policy has no such construct. > 5.2.2 shall ignore security attributes associated with unlabled user data Which security attributes? The kernel checks DAC first, so any existing Unix perms, ACLs etc. may take effect. > 8.6 newrole made into suid program so that it can send audit messages Why not instead define SELinux policy for the domain newrole runs in? (nlmsg_relay ?) Don't we also need some way to handle local mail delivery for different levels? - James -- James Morris From chanson at TrustedCS.com Wed Oct 5 05:02:37 2005 From: chanson at TrustedCS.com (Chad Hanson) Date: Wed, 5 Oct 2005 01:02:37 -0400 Subject: [redhat-lspp] LSPP work items Message-ID: <36282A1733C57546BE392885C0618592CE4CBA@chaos.tcs.tcs-sec.com> > > > 8.6 newrole made into suid program so that it can send > audit messages > > Why not instead define SELinux policy for the domain newrole runs in? > (nlmsg_relay ?) > > Auditing is allowed through Linux capabilities which require at least EUID root plus the proper domain. -Chad From rcoker at redhat.com Wed Oct 5 06:27:13 2005 From: rcoker at redhat.com (Russell Coker) Date: Wed, 05 Oct 2005 16:27:13 +1000 Subject: [redhat-lspp] LSPP work items In-Reply-To: <200510041746.52600.sgrubb@redhat.com> References: <200510041746.52600.sgrubb@redhat.com> Message-ID: <1128493633.3463.47.camel@aeon> On Tue, 2005-10-04 at 17:46 -0400, Steve Grubb wrote: > 1.2 There shall at least 16 levels of hierachial labels and 64 > compartments(L/FDP_IFF.2.7) however, we should have 256 compartments What do you mean by this? If you are talking about the default policy we are currently working with 128 compartments in MCS, changing it to 256 is easy enough. I think it's a good idea to have the same number of compartments for MCS and MLS - whenever we choose arbitrary numbers it makes sense to use the same ones everywhere. > 8 User Space SE Linux > 8.1 Admin shall be able to customize compartment names Is this in addition to the current system in rawhide where you can name complete MLS contexts only? > 8.6 newrole made into suid program so that it can send audit messages Is there another way of doing this? With the current design we have no SUID programs that are specific to SE Linux and no mechanism to allow SE Linux to permit operations that is not permitted by Unix permissions. This has clear benefits for the non-military use of SE Linux as it can be reasonably demonstrated that SE Linux can not decrease security (apart from issues such as potential bugs in SE Linux kernel code). As soon as we start with SUID SE Linux programs we will break this. Could we have something like a Unix domain socket interface to auditd which a SGID version of newrole would be able to write to? I know this is ugly but it seems the best of a set of bad options. > 9.4 Handles related operations like eject/close as part of the > allocation/unallocation so that the relabeling is synchronized with the > insertion of particular media. How will this work for floppy disks? In a PC there is no way of knowing when a floppy is inserted except by polling it. Or do we consider floppies to be obsoleted by CDs and USB flash devices? > 11.0 Postfix > 11.1 Add loginuid code to set it when delivering local mail (L/FIA_USB.1) One Postfix local process can deliver mail to multiple users. Is it permissable/desirable to allow it to set the loginuid and then set it back afterwards as it may be operating on behalf of multiple users. Alternatively it may be possible to modify the local process to exit after delivering each message. > 12.0 Procmail > 12.1 Add loginuid code to set it when delivering local mail (L/FIA_USB.1) Is this necessary if we get the Postfix local process (and equivalents in all other supported MTAs) to set it? For changes in regard to Procmail it would probably be good if we could change it to set an appropriate SE Linux context before doing anything. Alternatively we could have Procmail deprecated for sites that care about security (when I've talked about Procmail to people who audit code I've only had laughter in response). From sgrubb at redhat.com Wed Oct 5 10:29:26 2005 From: sgrubb at redhat.com (Steve Grubb) Date: Wed, 5 Oct 2005 06:29:26 -0400 Subject: [redhat-lspp] LSPP work items In-Reply-To: References: <200510041746.52600.sgrubb@redhat.com> Message-ID: <200510050629.26872.sgrubb@redhat.com> On Tuesday 04 October 2005 23:11, James Morris wrote: > > 3 Kernel - Audit related > > 3.1 Create new audit record types for: rlimit violations, lspp subject, > > lspp object, crypto, anomolies, and response to anomolies. > > What do you mean by crypto here? I am wanting to start getting the hooks in place for Medium Robustness. It says: Cryptography Admin role shall exist, Anything that inits the crypto, changing any of its params, algorithm modes, and selection of the algorithm shall require Crypto Admin role. I was intending to start putting the message types in the audit header files so that we can use them later. > > 4.3 When role data base is offline, corrupt, or unaccessable, the system > > shall preserve a secure state (R/FPT_FLS.1) > > What exactly does corrupt mean here: invalid file format or valid file > format with incorrect data? I guess both. > > 5 Kernel Export/Import of Data > > 5.1 Export of Data (FDP_ETC) > > 5.1.1 Export is controlled by MAC policy > > 5.1.2 unlabeled data stays unlabeled > > All data is labeled under SELinux in the kernel, but not necessarily > persistently. ?e.g. if you context mount an unlabeled partition, the > entire partition will be labeled while mounted but no labels will be > written to disk. LSPP says that if its unlabeled, it stays unlabeled unless explicitly labeled by the admin. > > 5.1.5 security mechanisms must be provided to the data that are exported > > by devices to media that do not have labels with the actual data > > What does this mean? ?Being able to differentiate access in policy based > on the labeling behavior of the device? ?SELinux policy has no such > construct. Good question. We've had a few discussions but no conclusions. It could be encrypted, for example. But does that mean we have FIPS requirements now? How we meet this needs discussion. > > 8.6 newrole made into suid program so that it can send audit messages > > Why not instead define SELinux policy for the domain newrole runs in? > (nlmsg_relay ?) We simply need CAP_AUDIT_WRITE. I was planning to drop capabilities on start up. > Don't we also need some way to handle local mail delivery for different > levels? Yes. Were we going to use postfix or just procmail? -Steve From sds at tycho.nsa.gov Wed Oct 5 12:45:38 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 05 Oct 2005 08:45:38 -0400 Subject: [redhat-lspp] audit messages CAPP vs LSPP In-Reply-To: <200510041308.15612.sgrubb@redhat.com> References: <200510041308.15612.sgrubb@redhat.com> Message-ID: <1128516338.24059.50.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-10-04 at 13:08 -0400, Steve Grubb wrote: > I was looking at the audit requirements. We need LSPP to coexist with CAPP. > Should the user space utilities send LSPP context information all the time > and let the kernel strip it out...or should there be a mode variable > somewhere that it can look at to decide if CAPP or LSPP information should be > sent? You don't want the individual utilities modifying the security contexts provided to them by libselinux. Now, libselinux does apply libsetrans to all contexts prior to returning them for context translation, so you could have different libsetrans implementations (or a single one with multiple modes), with the one implementation/mode stripping the MLS field and the other one not. In fact, the MCS libsetrans already does strip the :s0 from the contexts for display to users to reduce the delta from FC4. -- Stephen Smalley National Security Agency From sgrubb at redhat.com Wed Oct 5 13:29:18 2005 From: sgrubb at redhat.com (Steve Grubb) Date: Wed, 5 Oct 2005 09:29:18 -0400 Subject: [redhat-lspp] audit messages CAPP vs LSPP In-Reply-To: <1128516338.24059.50.camel@moss-spartans.epoch.ncsc.mil> References: <200510041308.15612.sgrubb@redhat.com> <1128516338.24059.50.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200510050929.18066.sgrubb@redhat.com> On Wednesday 05 October 2005 08:45, Stephen Smalley wrote: > You don't want the individual utilities modifying the security contexts > provided to them by libselinux. That's not what I meant. The applications need to collect the object information and send it to the kernel. The way the kernel will strip it is to not relay the message. So there would be 2 audit records sent, 1 for the event that's being recorded, and 1 for the object information. They would share the same event ID so that userspace tools tie them together. We are not talking about the kernel or the application modifying the actual information being sent. Its an all or nothing proposition. -Steve From sgrubb at redhat.com Wed Oct 5 14:58:31 2005 From: sgrubb at redhat.com (Steve Grubb) Date: Wed, 5 Oct 2005 10:58:31 -0400 Subject: [redhat-lspp] Idenifying Removable Media Message-ID: <200510051058.31819.sgrubb@redhat.com> Hi, A question came up. When media is inserted, there are 3 possibilities if its ext3 partition. It could be a plain ext3 partition from a RHEL3 machine, it could have some SE Linux information from FC3/4, or it could have MLS information. How do we identify the media and treat it appropriately so that its not seen as corrupted by the native machine when the media is returned? From a LSPP perspective, should extended attributes not be written to plain ext3 partition? How would someone check it? This same issue comes up on dual boot machines. -Steve From serue at us.ibm.com Wed Oct 5 15:08:57 2005 From: serue at us.ibm.com (serue at us.ibm.com) Date: Wed, 5 Oct 2005 10:08:57 -0500 Subject: [redhat-lspp] LSPP work items In-Reply-To: <200510050629.26872.sgrubb@redhat.com> References: <200510041746.52600.sgrubb@redhat.com> <200510050629.26872.sgrubb@redhat.com> Message-ID: <20051005150857.GB8515@sergelap.austin.ibm.com> Quoting Steve Grubb (sgrubb at redhat.com): > On Tuesday 04 October 2005 23:11, James Morris wrote: > > > 3 Kernel - Audit related > > > 3.1 Create new audit record types for: rlimit violations, lspp subject, > > > lspp object, crypto, anomolies, and response to anomolies. > > > > What do you mean by crypto here? > > I am wanting to start getting the hooks in place for Medium Robustness. It > says: Cryptography Admin role shall exist, Anything that inits the crypto, > changing any of its params, algorithm modes, and selection of the algorithm > shall require Crypto Admin role. Given that linux can't meet mrmlospp (iiuc), are you just planning on meeting whatever requirements are possible, or do you have some other Master Plan? Don't get me wrong, I'm all for a crypto admin role, I'm just wondering what the long term plans are. thanks, -serge From sgrubb at redhat.com Wed Oct 5 15:27:34 2005 From: sgrubb at redhat.com (Steve Grubb) Date: Wed, 5 Oct 2005 11:27:34 -0400 Subject: [redhat-lspp] LSPP work items In-Reply-To: <20051005150857.GB8515@sergelap.austin.ibm.com> References: <200510041746.52600.sgrubb@redhat.com> <200510050629.26872.sgrubb@redhat.com> <20051005150857.GB8515@sergelap.austin.ibm.com> Message-ID: <200510051127.34585.sgrubb@redhat.com> On Wednesday 05 October 2005 11:08, serue at us.ibm.com wrote: > > I am wanting to start getting the hooks in place for Medium Robustness. > > It says: Cryptography Admin role shall exist, Anything that inits the > > crypto, changing any of its params, algorithm modes, and selection of the > > algorithm shall require Crypto Admin role. > > Given that linux can't meet mrmlospp (iiuc), are you just planning on > meeting whatever requirements are possible, or do you have some other > Master Plan? In this particular case, its just allocating a block of messages that would ultimately be used for crypto events. This is essentially done. It was discussed on the linux-audit mail list. > Don't get me wrong, I'm all for a crypto admin role, I'm just wondering > what the long term plans are. My other goal is to pick the low hanging fruit in the MR Profile. There is no way to meet MR, as you said, with out a lot of work. I have not made this task list public at this point. I have started the pam work for it though. There are a lot of good common sense things in that Profile that is worth picking up and not too much effort. -Steve From sds at tycho.nsa.gov Wed Oct 5 15:26:24 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 05 Oct 2005 11:26:24 -0400 Subject: [redhat-lspp] Idenifying Removable Media In-Reply-To: <200510051058.31819.sgrubb@redhat.com> References: <200510051058.31819.sgrubb@redhat.com> Message-ID: <1128525984.24059.193.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2005-10-05 at 10:58 -0400, Steve Grubb wrote: > A question came up. When media is inserted, there are 3 possibilities if its > ext3 partition. It could be a plain ext3 partition from a RHEL3 machine, it > could have some SE Linux information from FC3/4, or it could have MLS > information. > > How do we identify the media and treat it appropriately so that its not seen > as corrupted by the native machine when the media is returned? From a LSPP > perspective, should extended attributes not be written to plain ext3 > partition? How would someone check it? > > This same issue comes up on dual boot machines. For exchanging between non-SELinux and SELinux systems, any selinux attribute written to the media while it is mounted on the SELinux system should just be ignored when it is mounted on the non-SELinux system. There was an xattr-on-symlinks compatibility issue a long time ago for 2.4 kernels, but that was fixed. For exchanging between non-MLS SELinux and MLS SELinux systems, there is presently an issue, since any files created while the media is mounted on the MLS SELinux system will get an extended attribute value with a MLS level in it, which will not be valid on the non-MLS SELinux system. (Side bar: Such media should likely always be mounted on the MLS SELinux system with a context mount option to explicitly set the level, although it will work without one due to the defaulting logic introduced by James in 2.6.13. That would prevent setxattr on the media from occurring. But it appears that it wouldn't prevent new files from having their extended attribute set by the fs code - looks like we would need to adjust inode_init_security to _not_ return the (name,context) pair for mountpoint labeled filesystem to avoid that. Thoughts? If we made that change, then we could just use context mounts for removable media and avoid any problems with exchange there. It would still be an issue for dual boots.) "Plain ext3 partition" seems a bit misleading, as there is no fundamental difference. Just the presence or absence of security xattrs (SELinux vs. non-SELinux), and just the presence or absence of a MLS level in the xattr values (MLS SELinux vs. non-MLS SELinux). SELinux does get the xattr of the root directory when the filesystem is mounted, so it can detect those states at that time. But I don't think you want SELinux automatically disabling setxattr and new file labeling just because the partition wasn't labeled originally; that used to be the norm for installing SELinux on a pre-existing non-SELinux system. Likewise for non-MLS to MLS (or MCS) upgrade. I suspect that we need to make a change to the non-MLS case to make it forgiving of the presence of the MLS level (i.e. ignore it) and back port that as needed for the dual boot case, so that a FC4/RHEL4 instance can access files created while running a FC5/RHEL5 instance. -- Stephen Smalley National Security Agency From jmorris at redhat.com Wed Oct 5 15:41:18 2005 From: jmorris at redhat.com (James Morris) Date: Wed, 5 Oct 2005 11:41:18 -0400 (EDT) Subject: [redhat-lspp] LSPP work items In-Reply-To: <200510050629.26872.sgrubb@redhat.com> References: <200510041746.52600.sgrubb@redhat.com> <200510050629.26872.sgrubb@redhat.com> Message-ID: On Wed, 5 Oct 2005, Steve Grubb wrote: > On Tuesday 04 October 2005 23:11, James Morris wrote: > > > 3 Kernel - Audit related > > > 3.1 Create new audit record types for: rlimit violations, lspp subject, > > > lspp object, crypto, anomolies, and response to anomolies. > > > > What do you mean by crypto here? > > I am wanting to start getting the hooks in place for Medium Robustness. It > says: Cryptography Admin role shall exist, Anything that inits the crypto, > changing any of its params, algorithm modes, and selection of the algorithm > shall require Crypto Admin role. > > I was intending to start putting the message types in the audit header files > so that we can use them later. We're some way off integrating crypto into SELinux policy, so I'd recommend not putting in unused infrastructure. > > > 4.3 When role data base is offline, corrupt, or unaccessable, the system > > > shall preserve a secure state (R/FPT_FLS.1) > > > > What exactly does corrupt mean here: invalid file format or valid file > > format with incorrect data? > > I guess both. Well, one is simple, the other is very difficult. We already detect and handle invalid file formats. We'd need an IDS to detect modifications to the role database. > > > 5 Kernel Export/Import of Data > > > 5.1 Export of Data (FDP_ETC) > > > 5.1.1 Export is controlled by MAC policy > > > 5.1.2 unlabeled data stays unlabeled > > > > All data is labeled under SELinux in the kernel, but not necessarily > > persistently. ?e.g. if you context mount an unlabeled partition, the > > entire partition will be labeled while mounted but no labels will be > > written to disk. > > LSPP says that if its unlabeled, it stays unlabeled unless explicitly labeled > by the admin. We have unlabeled_t, which means "this information is not labeled". There is no way we'll ever have completely unlabeled data in the system. - James -- James Morris From ltcgcw at us.ibm.com Wed Oct 5 15:47:36 2005 From: ltcgcw at us.ibm.com (George Wilson) Date: Wed, 05 Oct 2005 10:47:36 -0500 Subject: [redhat-lspp] LSPP work items In-Reply-To: <20051005150857.GB8515@sergelap.austin.ibm.com> References: <200510041746.52600.sgrubb@redhat.com> <200510050629.26872.sgrubb@redhat.com> <20051005150857.GB8515@sergelap.austin.ibm.com> Message-ID: <1128527256.13916.32.camel@ea.austin.ibm.com> On Wed, 2005-10-05 at 10:08 -0500, serue at us.ibm.com wrote: > Quoting Steve Grubb (sgrubb at redhat.com): > > On Tuesday 04 October 2005 23:11, James Morris wrote: > > > > 3 Kernel - Audit related > > > > 3.1 Create new audit record types for: rlimit violations, lspp subject, > > > > lspp object, crypto, anomolies, and response to anomolies. > > > > > > What do you mean by crypto here? > > > > I am wanting to start getting the hooks in place for Medium Robustness. It > > says: Cryptography Admin role shall exist, Anything that inits the crypto, > > changing any of its params, algorithm modes, and selection of the algorithm > > shall require Crypto Admin role. > > Given that linux can't meet mrmlospp (iiuc), are you just planning on > meeting whatever requirements are possible, or do you have some other > Master Plan? > > Don't get me wrong, I'm all for a crypto admin role, I'm just wondering > what the long term plans are. > > thanks, > -serge > > -- > redhat-lspp mailing list > redhat-lspp at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-lspp > Decomposing administrative roles is a generally a good thing where we can do so meaningfully. And no doubt certain MLOSPP features, such as trusted path, would be useful to have on an MLS system. But if I read MLOSPP correctly, it isn't easily achievable without meeting onerous FIPS crypto requirements and adding integrity labels. Moreover, the new draft is not yet complete and validated. I'm not convinced that it is worthwhile to make numerous changes to meet additional requirements if that work diverts our energy from meeting LSPP/RBACPP in the nearterm. I'm not saying we should box ourselves in. It is desirable to meet LSPP/RBACPP with an eye toward the future. However, let's please not take on too many requirements for a protection profile that is in motion, very difficult to meet, and not our current goal. -- George Wilson IBM Linux Technology Center From sgrubb at redhat.com Wed Oct 5 15:58:02 2005 From: sgrubb at redhat.com (Steve Grubb) Date: Wed, 5 Oct 2005 11:58:02 -0400 Subject: [redhat-lspp] LSPP work items In-Reply-To: References: <200510041746.52600.sgrubb@redhat.com> <200510050629.26872.sgrubb@redhat.com> Message-ID: <200510051158.02499.sgrubb@redhat.com> On Wednesday 05 October 2005 11:41, James Morris wrote: > > I was intending to start putting the message types in the audit header > > files so that we can use them later. > > We're some way off integrating crypto into SELinux policy, so I'd > recommend not putting in unused infrastructure. We've allocated a block of message numbers that can be used. That's the extent of it. > > > > 4.3 When role data base is offline, corrupt, or unaccessable, the > > > > system shall preserve a secure state (R/FPT_FLS.1) > > > > > > What exactly does corrupt mean here: invalid file format or valid file > > > format with incorrect data? > > > > I guess both. > > We'd need an IDS to detect modifications to the role database. What about tripwire? There is the requirement of the self test. I think it is supposed to catch things like this. Then I was also wondering if the policy file has a CRC or someway of detecting simple corruption? -Steve From dwalsh at redhat.com Wed Oct 5 16:03:23 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 05 Oct 2005 12:03:23 -0400 Subject: [redhat-lspp] LSPP work items In-Reply-To: <1128527256.13916.32.camel@ea.austin.ibm.com> References: <200510041746.52600.sgrubb@redhat.com> <200510050629.26872.sgrubb@redhat.com> <20051005150857.GB8515@sergelap.austin.ibm.com> <1128527256.13916.32.camel@ea.austin.ibm.com> Message-ID: <4343F94B.1060905@redhat.com> George Wilson wrote: > On Wed, 2005-10-05 at 10:08 -0500, serue at us.ibm.com wrote: > >> Quoting Steve Grubb (sgrubb at redhat.com): >> >>> On Tuesday 04 October 2005 23:11, James Morris wrote: >>> >>>>> 3 Kernel - Audit related >>>>> 3.1 Create new audit record types for: rlimit violations, lspp subject, >>>>> lspp object, crypto, anomolies, and response to anomolies. >>>>> >>>> What do you mean by crypto here? >>>> >>> I am wanting to start getting the hooks in place for Medium Robustness. It >>> says: Cryptography Admin role shall exist, Anything that inits the crypto, >>> changing any of its params, algorithm modes, and selection of the algorithm >>> shall require Crypto Admin role. >>> >> Given that linux can't meet mrmlospp (iiuc), are you just planning on >> meeting whatever requirements are possible, or do you have some other >> Master Plan? >> >> Don't get me wrong, I'm all for a crypto admin role, I'm just wondering >> what the long term plans are. >> >> thanks, >> -serge >> >> -- >> redhat-lspp mailing list >> redhat-lspp at redhat.com >> https://www.redhat.com/mailman/listinfo/redhat-lspp >> >> > > Decomposing administrative roles is a generally a good thing where we > can do so meaningfully. And no doubt certain MLOSPP features, such as > trusted path, would be useful to have on an MLS system. But if I read > MLOSPP correctly, it isn't easily achievable without meeting onerous > FIPS crypto requirements and adding integrity labels. Moreover, the new > draft is not yet complete and validated. I'm not convinced that it is > worthwhile to make numerous changes to meet additional requirements if > that work diverts our energy from meeting LSPP/RBACPP in the nearterm. > I'm not saying we should box ourselves in. It is desirable to meet > LSPP/RBACPP with an eye toward the future. However, let's please not > take on too many requirements for a protection profile that is in > motion, very difficult to meet, and not our current goal. > > I agree these items should be moved into a separate category of Nice to have, but lets not keep focus on getting LSPP/RBAC. -- From jmorris at redhat.com Wed Oct 5 16:52:27 2005 From: jmorris at redhat.com (James Morris) Date: Wed, 5 Oct 2005 12:52:27 -0400 (EDT) Subject: [redhat-lspp] LSPP work items In-Reply-To: <200510051158.02499.sgrubb@redhat.com> References: <200510041746.52600.sgrubb@redhat.com> <200510050629.26872.sgrubb@redhat.com> <200510051158.02499.sgrubb@redhat.com> Message-ID: On Wed, 5 Oct 2005, Steve Grubb wrote: > > We'd need an IDS to detect modifications to the role database. > > What about tripwire? There is the requirement of the self test. I think it is > supposed to catch things like this. Then I was also wondering if the policy > file has a CRC or someway of detecting simple corruption? rpm -V might be enough. -- James Morris From sgrubb at redhat.com Wed Oct 5 16:52:42 2005 From: sgrubb at redhat.com (Steve Grubb) Date: Wed, 5 Oct 2005 12:52:42 -0400 Subject: [redhat-lspp] LSPP work items In-Reply-To: <4343F94B.1060905@redhat.com> References: <200510041746.52600.sgrubb@redhat.com> <1128527256.13916.32.camel@ea.austin.ibm.com> <4343F94B.1060905@redhat.com> Message-ID: <200510051252.42073.sgrubb@redhat.com> On Wednesday 05 October 2005 12:03, Daniel J Walsh wrote: > I agree these items should be moved into a separate category of Nice to > have, but lets keep focus on getting LSPP/RBAC. Which is why I haven't pushed them out to this mail list. Back to the list I put out, I have identified one omission: 2.7 Create standard lspp audit config/rules Are there any other omissions that people can think of? Are there any things that should be deleted? -Steve From sgrubb at redhat.com Wed Oct 5 16:58:07 2005 From: sgrubb at redhat.com (Steve Grubb) Date: Wed, 5 Oct 2005 12:58:07 -0400 Subject: [redhat-lspp] LSPP work items In-Reply-To: References: <200510041746.52600.sgrubb@redhat.com> <200510051158.02499.sgrubb@redhat.com> Message-ID: <200510051258.07046.sgrubb@redhat.com> On Wednesday 05 October 2005 12:52, James Morris wrote: > rpm -V might be enough. The cert rpm config script will modify some permissions to various programs and files. rpm -V alone will be messy. One thing that I think this highlights is that we should probably create a reference cert config script that can be customized. This way we can see if rpm -V is messy and how we can clean it up. I also believe that a standard lspp audit config needs to be created, too. For both of these, I think it should be at the beginning of the project and not at the end. This way we know if we have problems well before development stops. Both of these are on the work items list. -Steve From klaus at atsec.com Wed Oct 5 19:12:14 2005 From: klaus at atsec.com (Klaus Weidner) Date: Wed, 5 Oct 2005 14:12:14 -0500 Subject: [redhat-lspp] LSPP work items In-Reply-To: <200510041746.52600.sgrubb@redhat.com> References: <200510041746.52600.sgrubb@redhat.com> Message-ID: <20051005191214.GA12239@w-m-p.com> On Tue, Oct 04, 2005 at 05:46:52PM -0400, Steve Grubb wrote: > 1.1 Objects shall include: files, named pipes (fifo), sockets, devices, shared > memory, message queue, semaphores. New object: kernel keys Kernel keys add many additional requirements for documentation, audit, and testing. I think it would be far easier to have a way to switch off the kernel key functionality for the evaluated config. I'm not objecting to adding SELinux support to the keys, but I think it's an optional feature that shouldn't be needed for an initial pass for meeting the PP. > 4.3 When role data base is offline, corrupt, or unaccessable, the system shall > preserve a secure state (R/FPT_FLS.1) I would interpret this in a straightforward way - a corrupt role data base is one that can't be loaded due to syntactical or other fundanmental errors. The point here is that the system handles a load error in a fail secure way and doesn't just continue with a partial or empty data base. I don't see this as implying a requirement to detect unauthorized modification. > 4.4 RBAC stipulates that after a failure or service discontinuity, the machine > shall enter a maintenance mode whereby the machine can be restored to a > secure state. Maybe config param for rc.sysinit (R/FPT_RCV.1) How about something similar to creating a "bad-system-state" file on boot that's removed only on a clean shutdown? If the file exists on boot, the system enters single user mode. This would work together with the existing auditd features to enter single user mode on audit failure, and something similar could be done for the SELinux policy loader. > 11.0 Postfix > 11.1 Add loginuid code to set it when delivering local mail (L/FIA_USB.1) > > 12.0 Procmail > 12.1 Add loginuid code to set it when delivering local mail (L/FIA_USB.1) I'd still consider this to be optional, an alternative is to disable user defined program execution via .forward files. Admins can still create global program aliases if needed. > 21 Turing Complete Programs > 21.1 Review all Turing complete programs to see if they need augmentation: > sed, awk, rpm, bash, tcsh, perl, python, postscript, m4, cpp What is this all about? The system's security features (kernel + trusted programs) need to be be sufficient to implement the requirements, and programs that aren't security enforcing shouldn't need to be touched. I don't see a reliable way to make this list complete, and what keeps users from installing their own copy of a programming language? -Klaus From dvelarde at us.ibm.com Wed Oct 5 19:16:51 2005 From: dvelarde at us.ibm.com (Debora Velarde) Date: Wed, 5 Oct 2005 14:16:51 -0500 Subject: [redhat-lspp] Idenifying Removable Media In-Reply-To: <1128525984.24059.193.camel@moss-spartans.epoch.ncsc.mil> Message-ID: redhat-lspp-bounces at redhat.com wrote on 10/05/2005 10:26:24 AM: > On Wed, 2005-10-05 at 10:58 -0400, Steve Grubb wrote: > > A question came up. When media is inserted, there are 3 > possibilities if its > > ext3 partition. It could be a plain ext3 partition from a RHEL3 machine, it > > could have some SE Linux information from FC3/4, or it could have MLS > > information. > > > > How do we identify the media and treat it appropriately so that > its not seen > > as corrupted by the native machine when the media is returned? From a LSPP > > perspective, should extended attributes not be written to plain ext3 > > partition? How would someone check it? > > > > This same issue comes up on dual boot machines. > > For exchanging between non-SELinux and SELinux systems, any selinux > attribute written to the media while it is mounted on the SELinux system > should just be ignored when it is mounted on the non-SELinux system. > There was an xattr-on-symlinks compatibility issue a long time ago for > 2.4 kernels, but that was fixed. > > For exchanging between non-MLS SELinux and MLS SELinux systems, there is > presently an issue, since any files created while the media is mounted > on the MLS SELinux system will get an extended attribute value with a > MLS level in it, which will not be valid on the non-MLS SELinux system. > > (Side bar: Such media should likely always be mounted on the MLS > SELinux system with a context mount option to explicitly set the level, > although it will work without one due to the defaulting logic introduced > by James in 2.6.13. That would prevent setxattr on the media from > occurring. But it appears that it wouldn't prevent new files from > having their extended attribute set by the fs code - looks like we would > need to adjust inode_init_security to _not_ return the (name,context) > pair for mountpoint labeled filesystem to avoid that. Thoughts? If we > made that change, then we could just use context mounts for removable > media and avoid any problems with exchange there. It would still be an > issue for dual boots.) > > "Plain ext3 partition" seems a bit misleading, as there is no > fundamental difference. Just the presence or absence of security xattrs > (SELinux vs. non-SELinux), and just the presence or absence of a MLS > level in the xattr values (MLS SELinux vs. non-MLS SELinux). SELinux > does get the xattr of the root directory when the filesystem is mounted, > so it can detect those states at that time. But I don't think you want > SELinux automatically disabling setxattr and new file labeling just > because the partition wasn't labeled originally; that used to be the > norm for installing SELinux on a pre-existing non-SELinux system. > Likewise for non-MLS to MLS (or MCS) upgrade. > > I suspect that we need to make a change to the non-MLS case to make it > forgiving of the presence of the MLS level (i.e. ignore it) and back > port that as needed for the dual boot case, so that a FC4/RHEL4 instance > can access files created while running a FC5/RHEL5 instance. > > -- > Stephen Smalley > National Security Agency > > -- > redhat-lspp mailing list > redhat-lspp at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-lspp I've been working on adding xattr support to zip and unzip. I have a question about what the correct behavior should be when you zip up a file on an MLS system and then unzip it on a non-MLS system. Right now, when I run unzip on the non-MLS system, my call to setxattr fails because of the MLS level. Should the right behavior be: 1. Delete the unzipped files if the xattr could not be successfully set. Then report an error that it was not successfully unzipped because of an xattr problem. 2. Go ahead and extract all the files. But report a warning that the extended attributes were not successfully set? 3. If the setxattr fails when trying to set "security.selinux", should I then try to remove the MLS level from the value and attempt to set that? Thanks, debbie From chrisw at osdl.org Wed Oct 5 19:20:25 2005 From: chrisw at osdl.org (Chris Wright) Date: Wed, 5 Oct 2005 12:20:25 -0700 Subject: [redhat-lspp] LSPP work items In-Reply-To: <20051005191214.GA12239@w-m-p.com> References: <200510041746.52600.sgrubb@redhat.com> <20051005191214.GA12239@w-m-p.com> Message-ID: <20051005192025.GB16352@shell0.pdx.osdl.net> * Klaus Weidner (klaus at atsec.com) wrote: > On Tue, Oct 04, 2005 at 05:46:52PM -0400, Steve Grubb wrote: > > 1.1 Objects shall include: files, named pipes (fifo), sockets, devices, shared > > memory, message queue, semaphores. New object: kernel keys > > Kernel keys add many additional requirements for documentation, audit, > and testing. I think it would be far easier to have a way to switch off > the kernel key functionality for the evaluated config. It's a kernel config item, so trivial to turn off. That is a maintenance issue, however, if standard shipped config has it enabled. > I'm not objecting to adding SELinux support to the keys, but I think it's > an optional feature that shouldn't be needed for an initial pass for > meeting the PP. There's timeframe to be concerned of, there's no label support for key infrastrucuture yet (although patches have recently been posted to add LSM support, so likely not a real issue). thanks, -chris From klaus at atsec.com Wed Oct 5 19:31:17 2005 From: klaus at atsec.com (Klaus Weidner) Date: Wed, 5 Oct 2005 14:31:17 -0500 Subject: [redhat-lspp] LSPP work items In-Reply-To: <20051005192025.GB16352@shell0.pdx.osdl.net> References: <200510041746.52600.sgrubb@redhat.com> <20051005191214.GA12239@w-m-p.com> <20051005192025.GB16352@shell0.pdx.osdl.net> Message-ID: <20051005193117.GB12239@w-m-p.com> On Wed, Oct 05, 2005 at 12:20:25PM -0700, Chris Wright wrote: > * Klaus Weidner (klaus at atsec.com) wrote: > > Kernel keys add many additional requirements for documentation, audit, > > and testing. I think it would be far easier to have a way to switch off > > the kernel key functionality for the evaluated config. > > It's a kernel config item, so trivial to turn off. That is a maintenance > issue, however, if standard shipped config has it enabled. I think it would be worthwhile to add a kernel boot parameter or some other runtime switch so that it can be turned off without needing a specially built kernel. -Klaus From sds at tycho.nsa.gov Wed Oct 5 19:37:25 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 05 Oct 2005 15:37:25 -0400 Subject: [redhat-lspp] Idenifying Removable Media In-Reply-To: References: Message-ID: <1128541045.24059.220.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2005-10-05 at 14:16 -0500, Debora Velarde wrote: > I've been working on adding xattr support to zip and unzip. I have a > question about what the correct behavior should be when you zip up a file > on an MLS system and then unzip it on a non-MLS system. Right now, when I > run unzip on the non-MLS system, my call to setxattr fails because of the > MLS level. Should the right behavior be: > 1. Delete the unzipped files if the xattr could not be successfully set. > Then report an error that it was not successfully unzipped because of an > xattr problem. > 2. Go ahead and extract all the files. But report a warning that the > extended attributes were not successfully set? > 3. If the setxattr fails when trying to set "security.selinux", should I > then try to remove the MLS level from the value and attempt to set that? A few points: - You could use setfscreatecon() before creating the file rather than setxattr after creating it so that you will get an indication that the context is invalid prior to creating the file and so that the file is immediately created in the right context if the context is valid. - If context preservation by unzip is optional (i.e. the user has to specify an option to enable it, like the current -X option for preserving uid/gid), then treating a failure as a fatal error condition for that particular file seems reasonable (the user can always extract the file without the option if desired). If context preservation is mandatory, then proceeding with a warning is likely necessary. - You could have a failure simply due to the type in the context not being defined in the policy on the machine, e.g. unzip'ing an archive that was created on a strict policy machine on a targeted policy machine, even without MLS coming into play. But at least the archive would include a human-readable context, so there is some hope that it could be translated to a local policy via some other mechanism. -- Stephen Smalley National Security Agency From William.Roe at gd-ais.com Wed Oct 5 19:41:44 2005 From: William.Roe at gd-ais.com (Roe, William H.) Date: Wed, 5 Oct 2005 15:41:44 -0400 Subject: [redhat-lspp] LSPP work items Message-ID: Forgive me if perhaps I missed this earlier and I did not see it discussed below. What about system label bracketing? E.g. ADMIN_LOW, user label1 ,user label 2, ADMIN_HIGH Where ADMIN_LOW is always the lowest label on the system and ADMIN_HIGH always dominates regardless of defined labels. That way an admin can always get to the data, even after a label change. E.g. ADMIN_HIGH always dominates. All audit files and audit processes should be labeled ADMIN_HIGH. This is because the audit files always have the possiblility of containing system high data. Additionally, kernel configuration files that have label definitions must also be kept at ADMIN_HIGH. I bring this up because this was/is a common issue with Compartmented Mode Workstations, but I have not seen it addressed. My assuption is that I missed that thread. William Roe, CISSP, M.S. IA General Dynamics, IMS-EDIS-AIS Technical Engineering Matrix Manager Sr. Lead Software Engineer 410/859-2076 office 443/220-8910 blackberry william.roe at gd-ais.com Confidentiality Note: This e-mail is intended only for the person or entity to which it is addressed, and may contain information that is privileged, confidential, or otherwise protected from disclosure. Dissemination, distribution, or copying of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this e-mail in error, please notify the sender by reply e-mail, phone, or fax, and destroy the original message and all copies. Thank you. -----Original Message----- From: redhat-lspp-bounces at redhat.com [mailto:redhat-lspp-bounces at redhat.com] On Behalf Of Steve Grubb Sent: Tuesday, October 04, 2005 5:47 PM To: lspp-list Subject: [redhat-lspp] LSPP work items Hello, I have finished reviewing specs and have pulled together a sheet that has a number of work items in it. The list still needs vetting. I have labeled the items to show where they come from. I put R for RBAC and L for LSPP and then the section it came from. Some things are not in the specs, like 3.1, 3.11, or 3.12. But I think these are items that we want coverage on to make sure the system is solid. If there are no parenthesis, I did not find it in the specs. An example of this would be file system polyinstantiation. Please let me know if something is missing or doesn't look right. -Steve ================ 1. Basic 1.1 Objects shall include: files, named pipes (fifo), sockets, devices, shared memory, message queue, semaphores. New object: kernel keys 1.2 There shall at least 16 levels of hierachial labels and 64 compartments(L/FDP_IFF.2.7) however, we should have 256 compartments 1.3 RBAC access control is modeled on DAC (need clarification?). Users shall have right to set restrictions on their Objects (R/FMT_SMR.2) 2 Audit User Space 2.1 Events shall contain unique session identifier and/or terminal (R/FAU_SAR.1) 2.2 The ability to search on subject and object labels (L/FAU_SEL.1) 2.3 The ability to search based on type of access and role that enabled access (R/FAU_SAR.3) 2.4 The ability to search based on subject and object role (R/FAU_SAR.1) 2.5 There shall be a method to audit based on keys 2.6 There shall be a way to audit based on network address 3 Kernel - Audit related 3.1 Create new audit record types for: rlimit violations, lspp subject, lspp object, crypto, anomolies, and response to anomolies. 3.2 All Subjects and Objects shall be labeled - Network and kernel keys needed (L/FAU_GEN.1) 3.3 Subject & Object information must be labeled in events (L/FAU_SAR.3) 3.4 Role must be identified in events (R/FAU_GEN.1) 3.5 For access control actions, the role that made access possible has to be recorded. (R/FAU_GEN.1) 3.6 Audit events shall contain unique session identifier and/or terminal(R/FAU_SAR.1) 3.7 Audit events can be filtered by Object or Subject labels (L/FAU_SEL.1) 3.8 Audit events can be filtered by host identity, event type, users belonging to certain role, and access types. (R/FAU_SEL.1) 3.9 There shall be a method to audit based on keys 3.10 There shall be a way to audit based on network address 3.11 Loading MAC policy is auditable event 3.12 Changing policy booleans is auditable event 3.13 Service discontinuity is auditable event. (R/FPT_RCV.1) 3.14 When user space message is relayed, add a subject message to same event(L/FAU_GEN.1) 4 Kernel - MAC related 4.1 MAC policy shall allow what's specified by LSPP 4.2 All actions performed by MAC policy can be audited - grant or denied 4.3 When role data base is offline, corrupt, or unaccessable, the system shall preserve a secure state (R/FPT_FLS.1) 4.4 RBAC stipulates that after a failure or service discontinuity, the machine shall enter a maintenance mode whereby the machine can be restored to a secure state. Maybe config param for rc.sysinit (R/FPT_RCV.1) 5 Kernel Export/Import of Data 5.1 Export of Data (FDP_ETC) 5.1.1 Export is controlled by MAC policy 5.1.2 unlabeled data stays unlabeled 5.1.3 labeled data stays labeled 5.1.4 unlabeled devices cannot be used to export data unless a change of state is performed manually and it is audited 5.1.5 security mechanisms must be provided to the data that are exported by devices to media that do not have labels with the actual data 5.1.6 Hard Copy 5.1.6.1 hard copy data must be labeled on every page (FDP_ETC) 5.1.6.2 admin shall be able to specify label associated with the data. Overrides are an auditable event. (FDP_ETC) 5.1.6.3 each print job will have label on header page representing the "least upper bound" of the whole print job 5.1.6.4 each page will have the label representing the "least upper bound" of all data exported 5.2 Import of data (FDP_ITC) 5.2.1 Import is controlled by MAC policy 5.2.2 shall ignore security attributes associated with unlabled user data 5.2.3 devices used to import data without labels cannot do so if previously allocated to importing data with labels without a manual state change that is auditable 5.2.4 system must provide protection mechanism for data imported from unlabeled sources. 5.2.5 attributes from the user data will be retained when labeled 6 File System Poly-instantiation 6.1 We need to have this to make life easier 7 User RBAC utilities 7.1 User shall have the ability to see list of authorized Roles (R/FIA_ATD.1) 7.2 User shall have the ability to see any user attribute related to Roles (R/FIA_ATD.1) 7.3 User shall have the ability to change to any authorized Roles (R/FMT_SMR.2) 7.4 Access granting functions shall fail when policy or role database is inaccessable. (R/FPT_RCV.4) 8 User Space SE Linux 8.1 Admin shall be able to customize compartment names 8.2 All utilities that display contexts shall be updated to display compartments. They shall display the custom name. 8.3 Admin shall be able to assign roles to users (R/FMT_MSA.1) 8.4 Given a file, the Admin shall be able to determine who can access it 8.5 Standard MAC policy needs creating 8.6 newrole made into suid program so that it can send audit messages 8.7 assignment of user to role/se linux user is auditable. (R/FAU_GEN.1) 9 Device Allocator 9.1 Handles authorization of access to the device, 9.2 Handles synchronization of access to the device, 9.3 Determines the context to assign to the device node dynamically based on the allocating process, 9.4 Handles related operations like eject/close as part of the allocation/unallocation so that the relabeling is synchronized with the insertion of particular media. 10 Self Test 10.1 RBAC requires that a suite of tests be available that demonstrates that the machine is correctly operating. (R/FPT_TST.1) 10.2 Authorized users shall also be able to verify the integrity of data and executables called out in security target. (R/FPT_TST.1) 10.3 Tests shall produce audit records indicating that it was run and any failures. (R/FPT_TST.1) 11.0 Postfix 11.1 Add loginuid code to set it when delivering local mail (L/FIA_USB.1) 12.0 Procmail 12.1 Add loginuid code to set it when delivering local mail (L/FIA_USB.1) 13.0 Udev 13.1 No hotplug events shall label devices. It can only make sure they are unlabeled. (L/FDP_ETC, FDP_ITC) 14.0 initscripts 14.1 Shutdown needs hwclock call moved to before killing the audit daemon (L/FPT_STM.1) 15 cron 15.1 Multi-level cron 16 xinetd 16.1 Multi-level inetd is needed 17 Shadow-utils 17.1 update shadow-utils to insert object information in the messages (L/FAU_GEN.1) 18 util-linux 18.1 hwclock needs update for contexts (L/FAU_GEN.1) 18.2 login needs contexts update (L/FAU_GEN.1) 19 pam 19.1 various updates for labels 20 passwd 20.1 update to insert object information in the messages (L/FAU_GEN.1) 21 Turing Complete Programs 21.1 Review all Turing complete programs to see if they need augmentation: sed, awk, rpm, bash, tcsh, perl, python, postscript, m4, cpp -- redhat-lspp mailing list redhat-lspp at redhat.com https://www.redhat.com/mailman/listinfo/redhat-lspp From William.Roe at gd-ais.com Wed Oct 5 19:46:25 2005 From: William.Roe at gd-ais.com (Roe, William H.) Date: Wed, 5 Oct 2005 15:46:25 -0400 Subject: [redhat-lspp] Idenifying Removable Media Message-ID: CMW operating systems like trusted solaris prompt the user to identify the label level of the device or it will assume the label level of the running process. Therefore all files copied from that device are given the that label. William Roe, CISSP, M.S. IA General Dynamics, IMS-EDIS-AIS Technical Engineering Matrix Manager Sr. Lead Software Engineer 410/859-2076 office 443/220-8910 blackberry william.roe at gd-ais.com -----Original Message----- From: redhat-lspp-bounces at redhat.com [mailto:redhat-lspp-bounces at redhat.com] On Behalf Of Steve Grubb Sent: Wednesday, October 05, 2005 10:59 AM To: lspp-list Subject: [redhat-lspp] Idenifying Removable Media Hi, A question came up. When media is inserted, there are 3 possibilities if its ext3 partition. It could be a plain ext3 partition from a RHEL3 machine, it could have some SE Linux information from FC3/4, or it could have MLS information. How do we identify the media and treat it appropriately so that its not seen as corrupted by the native machine when the media is returned? From a LSPP perspective, should extended attributes not be written to plain ext3 partition? How would someone check it? This same issue comes up on dual boot machines. -Steve -- redhat-lspp mailing list redhat-lspp at redhat.com https://www.redhat.com/mailman/listinfo/redhat-lspp From jmorris at redhat.com Wed Oct 5 19:50:00 2005 From: jmorris at redhat.com (James Morris) Date: Wed, 5 Oct 2005 15:50:00 -0400 (EDT) Subject: [redhat-lspp] LSPP work items In-Reply-To: <20051005192025.GB16352@shell0.pdx.osdl.net> References: <200510041746.52600.sgrubb@redhat.com> <20051005191214.GA12239@w-m-p.com> <20051005192025.GB16352@shell0.pdx.osdl.net> Message-ID: On Wed, 5 Oct 2005, Chris Wright wrote: > > Kernel keys add many additional requirements for documentation, audit, > > and testing. I think it would be far easier to have a way to switch off > > the kernel key functionality for the evaluated config. > > It's a kernel config item, so trivial to turn off. That is a maintenance > issue, however, if standard shipped config has it enabled. We're only shipping one kernel, and this feature will be enabled. - James -- James Morris From sgrubb at redhat.com Wed Oct 5 19:49:56 2005 From: sgrubb at redhat.com (Steve Grubb) Date: Wed, 5 Oct 2005 15:49:56 -0400 Subject: [redhat-lspp] LSPP work items In-Reply-To: <20051005191214.GA12239@w-m-p.com> References: <200510041746.52600.sgrubb@redhat.com> <20051005191214.GA12239@w-m-p.com> Message-ID: <200510051549.56171.sgrubb@redhat.com> On Wednesday 05 October 2005 15:12, Klaus Weidner wrote: > > 1.1 Objects shall include: files, named pipes (fifo), sockets, devices, > > shared memory, message queue, semaphores. New object: kernel keys > > Kernel keys add many additional requirements for documentation, audit, > and testing. I think it would be far easier to have a way to switch off > the kernel key functionality for the evaluated config. Its a syscall interface. Presumably, people will be doing both CAPP and LSPP evals. How do you prevent this in CAPP? I think that with the amount of time that the next OS has for development, you may not be able to ignore it. Something important may be using it by then. > I'm not objecting to adding SELinux support to the keys, but I think it's > an optional feature that shouldn't be needed for an initial pass for > meeting the PP. That depends on what apps do with it. It might be required by the time RHEL5 is released. > > 4.3 When role data base is offline, corrupt, or unaccessable, the system > > shall preserve a secure state (R/FPT_FLS.1) > > I don't see this as implying a requirement to detect unauthorized > modification. Right, the consistency test does though. Is policy not a trusted database? > > 4.4 RBAC stipulates that after a failure or service discontinuity, the > > machine shall enter a maintenance mode whereby the machine can be > > restored to a secure state. Maybe config param for rc.sysinit > > (R/FPT_RCV.1) > > How about something similar to creating a "bad-system-state" file on boot > that's removed only on a clean shutdown? Can you not do a clean shutdown without fixing the problem? > If the file exists on boot, the system enters single user mode. Yes. This sounds reasonable. Just shouldn't be removed unless the utility fixes the database or the admin deletes it. > > 11.0 Postfix > > 11.1 Add loginuid code to set it when delivering local mail (L/FIA_USB.1) > > > > 12.0 Procmail > > 12.1 Add loginuid code to set it when delivering local mail (L/FIA_USB.1) > > I'd still consider this to be optional, an alternative is to disable user > defined program execution via .forward files. Admins can still create > global program aliases if needed. What account do they run under? > > 21 Turing Complete Programs > > 21.1 Review all Turing complete programs to see if they need > > augmentation: sed, awk, rpm, bash, tcsh, perl, python, postscript, m4, > > cpp > > What is this all about? The system's security features (kernel + trusted > programs) need to be be sufficient to implement the requirements, and > programs that aren't security enforcing shouldn't need to be touched. I agree, but I think I am going to hold on to these until enough of the system is implmented to determine if this is needed. This is more of a reminder to check this when we are about done. -Steve From sgrubb at redhat.com Wed Oct 5 19:52:29 2005 From: sgrubb at redhat.com (Steve Grubb) Date: Wed, 5 Oct 2005 15:52:29 -0400 Subject: [redhat-lspp] LSPP work items In-Reply-To: <20051005192025.GB16352@shell0.pdx.osdl.net> References: <200510041746.52600.sgrubb@redhat.com> <20051005191214.GA12239@w-m-p.com> <20051005192025.GB16352@shell0.pdx.osdl.net> Message-ID: <200510051552.29484.sgrubb@redhat.com> On Wednesday 05 October 2005 15:20, Chris Wright wrote: > It's a kernel config item, so trivial to turn off. ?That is a maintenance > issue, however, if standard shipped config has it enabled. Its intended to be on and used by our distro. -Steve From jmorris at redhat.com Wed Oct 5 19:53:37 2005 From: jmorris at redhat.com (James Morris) Date: Wed, 5 Oct 2005 15:53:37 -0400 (EDT) Subject: [redhat-lspp] LSPP work items In-Reply-To: <20051005193117.GB12239@w-m-p.com> References: <200510041746.52600.sgrubb@redhat.com> <20051005191214.GA12239@w-m-p.com> <20051005192025.GB16352@shell0.pdx.osdl.net> <20051005193117.GB12239@w-m-p.com> Message-ID: On Wed, 5 Oct 2005, Klaus Weidner wrote: > I think it would be worthwhile to add a kernel boot parameter or some > other runtime switch so that it can be turned off without needing a > specially built kernel. I've added David to the cc list in case he's not on redhat-lspp. Not sure how feasible or useful it would be to add a boot parameter for the key subsystem -- it introduces a system call, for example. - James -- James Morris From klaus at atsec.com Wed Oct 5 20:15:04 2005 From: klaus at atsec.com (Klaus Weidner) Date: Wed, 5 Oct 2005 15:15:04 -0500 Subject: [redhat-lspp] LSPP work items In-Reply-To: References: <200510041746.52600.sgrubb@redhat.com> <20051005191214.GA12239@w-m-p.com> <20051005192025.GB16352@shell0.pdx.osdl.net> <20051005193117.GB12239@w-m-p.com> Message-ID: <20051005201503.GC12239@w-m-p.com> On Wed, Oct 05, 2005 at 03:53:37PM -0400, James Morris wrote: > On Wed, 5 Oct 2005, Klaus Weidner wrote: > > I think it would be worthwhile to add a kernel boot parameter or some > > other runtime switch so that it can be turned off without needing a > > specially built kernel. > > I've added David to the cc list in case he's not on redhat-lspp. > > Not sure how feasible or useful it would be to add a boot parameter for > the key subsystem -- it introduces a system call, for example. Another option would be to turn it into a loadable module, this would probably be a more generally useful change than the boot time switch. I guess the system calls could be implemented as stubs that check for enablement / module presence and then call the real implementation, or ENOSYS if not available? -Klaus From sgrubb at redhat.com Wed Oct 5 20:16:41 2005 From: sgrubb at redhat.com (Steve Grubb) Date: Wed, 5 Oct 2005 16:16:41 -0400 Subject: [redhat-lspp] Idenifying Removable Media In-Reply-To: References: Message-ID: <200510051616.41278.sgrubb@redhat.com> On Wednesday 05 October 2005 15:46, Roe, William H. wrote: > CMW operating systems like trusted solaris prompt the user to identify > the label level of the device or it will assume the label level of the > running process. ?Therefore all files copied from that device are given > the that label. So when you take that media to a regular (not trusted) solaris machine and try to read it, can you read it? I don't want us to be causing users or developer's grief if they dual boot machines. -Steve From chanson at TrustedCS.com Wed Oct 5 20:24:07 2005 From: chanson at TrustedCS.com (Chad Hanson) Date: Wed, 5 Oct 2005 16:24:07 -0400 Subject: [redhat-lspp] Idenifying Removable Media Message-ID: <36282A1733C57546BE392885C0618592CE4E95@chaos.tcs.tcs-sec.com> This is simply talking about device allocation framework. If you allocate a cdrom at confidential, the data is treated as this. The output format can tar, cpio, etc..... which will work with all systems. The data files are not labeled on the export because the device is labeled and the media should marked as the label as well. -Chad > > On Wednesday 05 October 2005 15:46, Roe, William H. wrote: > > CMW operating systems like trusted solaris prompt the user > to identify > > the label level of the device or it will assume the label > level of the > > running process. ?Therefore all files copied from that > device are given > > the that label. > > So when you take that media to a regular (not trusted) > solaris machine and try > to read it, can you read it? I don't want us to be causing users or > developer's grief if they dual boot machines. > From chanson at TrustedCS.com Wed Oct 5 20:27:48 2005 From: chanson at TrustedCS.com (Chad Hanson) Date: Wed, 5 Oct 2005 16:27:48 -0400 Subject: [redhat-lspp] LSPP work items Message-ID: <36282A1733C57546BE392885C0618592CE4E9B@chaos.tcs.tcs-sec.com> > > Forgive me if perhaps I missed this earlier and I did not see it > discussed below. > > What about system label bracketing? E.g. ADMIN_LOW, user label1 ,user > label 2, ADMIN_HIGH > Not sure the exact context of this question... > Where ADMIN_LOW is always the lowest label on the system and > ADMIN_HIGH > always dominates regardless of defined labels. That way an admin can > always get to the data, even after a label change. E.g. ADMIN_HIGH > always dominates. > > All audit files and audit processes should be labeled > ADMIN_HIGH. This > is because the audit files always have the possiblility of containing > system high data. Additionally, kernel configuration files that have > label definitions must also be kept at ADMIN_HIGH. > > I bring this up because this was/is a common issue with Compartmented > Mode Workstations, but I have not seen it addressed. My assuption is > that I missed that thread. > Not sure if this has been explicitly discussed, but this is correct.... I think we are using SystemHigh for the current MCS file, we need to create the MLS translation library. -Chad From sgrubb at redhat.com Wed Oct 5 20:49:01 2005 From: sgrubb at redhat.com (Steve Grubb) Date: Wed, 5 Oct 2005 16:49:01 -0400 Subject: [redhat-lspp] LSPP work items In-Reply-To: <1128493633.3463.47.camel@aeon> References: <200510041746.52600.sgrubb@redhat.com> <1128493633.3463.47.camel@aeon> Message-ID: <200510051649.01679.sgrubb@redhat.com> On Wednesday 05 October 2005 02:27, Russell Coker wrote: > > 1.2 There shall at least 16 levels of hierachial labels and 64 > > compartments(L/FDP_IFF.2.7) however, we should have 256 compartments > > What do you mean by this? If you are talking about the default policy > we are currently working with 128 compartments in MCS, changing it to > 256 is easy enough. That exactly what I mean. Our LSPP policy should have 256 minimum. This would not be unreasonable. By doing this it will be tested so that we know it can handle it. > > 8 User Space SE Linux > > 8.1 Admin shall be able to customize compartment names > > Is this in addition to the current system in rawhide where you can name > complete MLS contexts only? No. I think its the same thing. > > 8.6 newrole made into suid program so that it can send audit messages > > Is there another way of doing this? Rather not. Too easy to abuse. We just drop all capabilities except CAP_AUDIT_WRITE on startup. Its real simple. > > 9.4 Handles related operations like eject/close as part of the > > allocation/unallocation so that the relabeling is synchronized with the > > insertion of particular media. > > How will this work for floppy disks? In a PC there is no way of knowing > when a floppy is inserted except by polling it. Or do we consider > floppies to be obsoleted by CDs and USB flash devices? The admin puts the disk in and runs the device allocator program. He runs it because he knows he put a disk in. > > 11.0 Postfix > > 11.1 Add loginuid code to set it when delivering local mail (L/FIA_USB.1) > > One Postfix local process can deliver mail to multiple users. Is it > permissable/desirable to allow it to set the loginuid and then set it > back afterwards as it may be operating on behalf of multiple users. Sort of. What would it set it back to? When it executes .foward files, it needs to set the loginuid so that any actions it performs is properly attributed to the owner of that file and not root/mail. > > 12.0 Procmail > > 12.1 Add loginuid code to set it when delivering local mail (L/FIA_USB.1) > > Is this necessary if we get the Postfix local process (and equivalents > in all other supported MTAs) to set it? Yes. People may chose to use it for local delivery. We need to make sure it works correctly. > For changes in regard to Procmail it would probably be good if we could > change it to set an appropriate SE Linux context before doing anything. This is a good idea, too. > Alternatively we could have Procmail deprecated for sites that care > about security (when I've talked about Procmail to people who audit code > I've only had laughter in response). Yes, its coding style is very...distinct. :) -Steve From William.Roe at gd-ais.com Wed Oct 5 20:52:58 2005 From: William.Roe at gd-ais.com (Roe, William H.) Date: Wed, 5 Oct 2005 16:52:58 -0400 Subject: [redhat-lspp] Idenifying Removable Media Message-ID: ISO9660 does not provide a label for files, nor does Joliet, etc. Therefore Yes. We still have to use physical markings on most media devices for so we can use portable file systems. Bill William Roe, CISSP, M.S. IA General Dynamics, IMS-EDIS-AIS Technical Engineering Matrix Manager Sr. Lead Software Engineer 410/859-2076 office 443/220-8910 blackberry william.roe at gd-ais.com -----Original Message----- From: redhat-lspp-bounces at redhat.com [mailto:redhat-lspp-bounces at redhat.com] On Behalf Of Steve Grubb Sent: Wednesday, October 05, 2005 4:17 PM To: lspp-list Subject: Re: [redhat-lspp] Idenifying Removable Media On Wednesday 05 October 2005 15:46, Roe, William H. wrote: > CMW operating systems like trusted solaris prompt the user to identify > the label level of the device or it will assume the label level of the > running process. ?Therefore all files copied from that device are > given the that label. So when you take that media to a regular (not trusted) solaris machine and try to read it, can you read it? I don't want us to be causing users or developer's grief if they dual boot machines. -Steve -- redhat-lspp mailing list redhat-lspp at redhat.com https://www.redhat.com/mailman/listinfo/redhat-lspp From rcoker at redhat.com Wed Oct 5 21:05:17 2005 From: rcoker at redhat.com (Russell Coker) Date: Thu, 06 Oct 2005 07:05:17 +1000 Subject: [redhat-lspp] LSPP work items In-Reply-To: <200510051649.01679.sgrubb@redhat.com> References: <200510041746.52600.sgrubb@redhat.com> <1128493633.3463.47.camel@aeon> <200510051649.01679.sgrubb@redhat.com> Message-ID: <1128546317.3463.96.camel@aeon> On Wed, 2005-10-05 at 06:36 -0400, Steve Grubb wrote: > On Wednesday 05 October 2005 02:27, you wrote: > > > 1.2 There shall at least 16 levels of hierachial labels and 64 > > > compartments(L/FDP_IFF.2.7) however, we should have 256 > > compartments > > What do you mean by this? If you are talking about the default > > policy > > we are currently working with 128 compartments in MCS, changing it > > to 256 is easy enough. > > That exactly what I mean. Our LSPP policy should have 256 minimum. > This would not be unreasonable. By doing this it will be tested so > that we know it can handle it. 256 sounds fine, it's a nice number. As for testing, isn't 2^16 where it starts to get difficult? I doubt that we need to do this for testing purposes. But if 256 is needed to meet the real requirements of the majority of customers we should do it. > > > 8 User Space SE Linux > > > 8.1 Admin shall be able to customize compartment names > > > > Is this in addition to the current system in rawhide where you can > > name complete MLS contexts only? > > No. I think its the same thing. I think we have some protocol mis-match problem in our communication. In the current setup it is simply impossible (AFAIK) to label a compartment (please tell me how to do it if you believe otherwise, I have checked the documentation and tried the reasonable options to no avail). What you can do is label a MLS category, we can label s0:c0 and we can label s0:c0.c1, we can't label c0 in a way that is applied regardless of level or in a way that applies even if there are other categories. If we wanted a label for c0 that applies everywhere then we have to have an entry in /etc/mcs.conf (I guess we will have /etc/mls.conf - maybe we should be using /etc/seclabel.conf or something) for c0 combined with every possible sensitivity level (you suggest 16), as well as for every possible combination of categories. So if c0 might be combined with 10 combinations of categories (just an arbitrary number, let's assume that 2^256 isn't required) and in each of the 16 levels then we need 160 entries in /etc/mcs.conf. > > > 8.6 newrole made into suid program so that it can send audit > > > messages > > > > Is there another way of doing this? > > Rather not. Too easy to abuse. We just drop all capabilities except > CAP_AUDIT_WRITE on startup. Its real simple. Wasn't there a Sendmail bug where it was supposed to do such things but didn't? > > > 9.4 Handles related operations like eject/close as part of the > > > allocation/unallocation so that the relabeling is synchronized > > > with the insertion of particular media. > > > > How will this work for floppy disks? In a PC there is no way of > > knowing > > when a floppy is inserted except by polling it. Or do we consider > > floppies to be obsoleted by CDs and USB flash devices? > > The admin puts the disk in and runs the device allocator program. He > runs it because he knows he put a disk in. OK, makes sense. > > > 11.0 Postfix > > > 11.1 Add loginuid code to set it when delivering local mail > > > (L/FIA_USB.1) > > > > One Postfix local process can deliver mail to multiple users. Is it > > permissable/desirable to allow it to set the loginuid and then set > > it back afterwards as it may be operating on behalf of multiple > > users. > > Sort of. What would it set it back to? When it executes .foward files, > it needs to set the loginuid so that any actions it performs is > properly attributed to the owner of that file and not root/mail. Anyway the Postfix "local" program performs system operations (loginuid==0), then operates on behalf of one user (loginuid==501), then back to system operations (loginuid==0) then on behalf of another user (loginuid==502). As for the .forward issue, it is parsed for multiple users by the same process. So it seems we have a problem in terms of contamination. I think that ideally a process that does ANYTHING with a user's data would change to the permissions of the user (at least one of UID or SE Linux context) in a manner that does not permit changing back. > > > 12.0 Procmail > > > 12.1 Add loginuid code to set it when delivering local mail > > > (L/FIA_USB.1) > > > > Is this necessary if we get the Postfix local process (and > > equivalents in all other supported MTAs) to set it? > > Yes. People may chose to use it for local delivery. We need to make > sure it works correctly. The postfix local process calls procmail. Therefore if the loginuid is set by the local process then procmail will inherit it without the need to do anything else. Changing procmail code will not be fun and is something that I think we want to avoid if possible. Ideally I think we would have the Postfix local process set the UID and SE Linux context of the user before executing Procmail. Then we will still face the issue of Procmail compromising the user's environment, but not the issue of the user's .forward file compromising the integrity of the system. From dvelarde at us.ibm.com Wed Oct 5 22:39:26 2005 From: dvelarde at us.ibm.com (Debora Velarde) Date: Wed, 5 Oct 2005 17:39:26 -0500 Subject: [redhat-lspp] zip & unzip - restoring labels? In-Reply-To: <1128541045.24059.220.camel@moss-spartans.epoch.ncsc.mil> Message-ID: I've been working on adding support for extended attributes, including "security.selinux" to zip & unzip. With MLS, a user should not be allowed to downgrade information, but upgrading it is okay. Therefore, I think the default behavior for zip and unzip should be to NOT try to restore the labels. For example, if a user zips up 3 files: 2 "unclassified" and 1 "top secret", then the resulting archive should be "top secret" (the least upper bound the process can be running at in order to zip up all 3 files). If that archive is moved to a different system, then it should also be "top secret" on the 2nd system. If that archive is unzipped on the 2nd system, all the extracted files will also be "top secret" because that is the level the process must be at in order to unzip the archive. Because we don't want someone to unintentionally downgrade information from "top secret" to "unclassified", unzip should only attempt to restore the labels if specified with a command line option. Thoughts? debbie From klaus at atsec.com Wed Oct 5 23:22:31 2005 From: klaus at atsec.com (Klaus Weidner) Date: Wed, 5 Oct 2005 18:22:31 -0500 Subject: [redhat-lspp] zip & unzip - restoring labels? In-Reply-To: References: <1128541045.24059.220.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20051005232231.GD12239@w-m-p.com> On Wed, Oct 05, 2005 at 05:39:26PM -0500, Debora Velarde wrote: > With MLS, a user should not be allowed to downgrade information, but > upgrading it is okay. > Therefore, I think the default behavior for zip and unzip should be to NOT > try to restore the labels. > > For example, if a user zips up 3 files: 2 "unclassified" and 1 "top > secret", then the resulting archive should be "top secret" (the least > upper bound the process can be running at in order to zip up all 3 files). > If that archive is moved to a different system, then it should also be > "top secret" on the 2nd system. > If that archive is unzipped on the 2nd system, all the extracted files > will also be "top secret" because that is the level the process must be at > in order to unzip the archive. > > Because we don't want someone to unintentionally downgrade information > from "top secret" to "unclassified", unzip should only attempt to restore > the labels if specified with a command line option. Not restoring labels (the behavior you describe above) needs to be the only one available to regular users, and is the only one possible without giving special privileges to unzip; doing that would be a huge security hole. Restoring labels can only work for an administrator, similar to how tar only restores user IDs when run as root. It would be the admin's responsibility to make sure that the extracted rights make sense. I'm neutral about whether it should produce a fatal error or warning if it can't set the context, as long as it's clear to the admin what happened. You can't expect a tool like tar or unzip to automatically do the right thing, it's the admin's responsibility to make sure everything works right. -Klaus From rcoker at redhat.com Thu Oct 6 05:08:19 2005 From: rcoker at redhat.com (Russell Coker) Date: Thu, 06 Oct 2005 15:08:19 +1000 Subject: [redhat-lspp] zip & unzip - restoring labels? In-Reply-To: <20051005232231.GD12239@w-m-p.com> References: <1128541045.24059.220.camel@moss-spartans.epoch.ncsc.mil> <20051005232231.GD12239@w-m-p.com> Message-ID: <1128575299.3463.111.camel@aeon> On Wed, 2005-10-05 at 18:22 -0500, Klaus Weidner wrote: > On Wed, Oct 05, 2005 at 05:39:26PM -0500, Debora Velarde wrote: [snipped why zip as a non-admin should not have MLS support] > Restoring labels can only work for an administrator, similar to how tar > only restores user IDs when run as root. It would be the admin's > responsibility to make sure that the extracted rights make sense. We don't support zip/unzip as backup tools, so it seems to me that we have no LSPP requirements for preserving labels given Debora's analysis of the situation. Whether we want to have zip/unzip support SE Linux contexts (for DT functionality) seems a separate issue. I guess that DT support in tools such as zip/unzip is not a LSPP requirement. From jmorris at redhat.com Thu Oct 6 06:21:51 2005 From: jmorris at redhat.com (James Morris) Date: Thu, 6 Oct 2005 02:21:51 -0400 (EDT) Subject: [redhat-lspp] LSPP work items In-Reply-To: <20051005201503.GC12239@w-m-p.com> References: <200510041746.52600.sgrubb@redhat.com> <20051005191214.GA12239@w-m-p.com> <20051005192025.GB16352@shell0.pdx.osdl.net> <20051005193117.GB12239@w-m-p.com> <20051005201503.GC12239@w-m-p.com> Message-ID: On Wed, 5 Oct 2005, Klaus Weidner wrote: > On Wed, Oct 05, 2005 at 03:53:37PM -0400, James Morris wrote: > > On Wed, 5 Oct 2005, Klaus Weidner wrote: > > > I think it would be worthwhile to add a kernel boot parameter or some > > > other runtime switch so that it can be turned off without needing a > > > specially built kernel. > > > > I've added David to the cc list in case he's not on redhat-lspp. > > > > Not sure how feasible or useful it would be to add a boot parameter for > > the key subsystem -- it introduces a system call, for example. > > Another option would be to turn it into a loadable module, this would > probably be a more generally useful change than the boot time switch. I > guess the system calls could be implemented as stubs that check for > enablement / module presence and then call the real implementation, or > ENOSYS if not available? This may be feasible. I'm not clear on whether there are any existing in-kernel users of this subsystem (still looking at the code in more detail). So perhaps a modular version has some more general use. One thing I'm concerned at, which I suspect you may be, is that if we include key objects in LSPP, then we may need to go further than just "access to objects" and start looking at the semantics of the keys, effectively implementing crypto policy. e.g. it may not just be enough to have labels assigned to keys, but to have those labels reflect the content of the keys (e.g. "high_assurance_cipher_t"). Is this likely to be the case? If so, it's opening a can of worms we really need to leave until MLOSPP or similar. In any case, if there are no significant in-tree users of the key subsystem, then I'm not sure we need to include this subsystem in the LSPP evaluation. David: can you explain who is using this code and whether you think it could be made modular? - James -- James Morris From rcoker at redhat.com Thu Oct 6 09:18:09 2005 From: rcoker at redhat.com (Russell Coker) Date: Thu, 06 Oct 2005 19:18:09 +1000 Subject: [redhat-lspp] LSPP work items In-Reply-To: <20051005191214.GA12239@w-m-p.com> References: <200510041746.52600.sgrubb@redhat.com> <20051005191214.GA12239@w-m-p.com> Message-ID: <1128590289.3463.114.camel@aeon> On Wed, 2005-10-05 at 14:12 -0500, Klaus Weidner wrote: > > 21 Turing Complete Programs > > 21.1 Review all Turing complete programs to see if they need > augmentation: > > sed, awk, rpm, bash, tcsh, perl, python, postscript, m4, cpp > > What is this all about? The system's security features (kernel + > trusted > programs) need to be be sufficient to implement the requirements, and > programs that aren't security enforcing shouldn't need to be touched. > I don't see a reliable way to make this list complete, and what keeps > users from installing their own copy of a programming language? Preventing execute access of all types that a user can write is not so difficult, so it is possible to prevent the user from installing their own copy of a programming language. Of course if a user could install a programming language they could more easily install a binary produced by an optimising compiler which would be much smaller. There is a big demand for preventing a user from running any code, preventing the user from running arbitrary shell scripts etc is necessary to provide that feature. I'm not sure that the people who demand such a feature are being sensible though. There is nothing stopping an attacker from using expect on the attacking machine to run programs... From dhowells at redhat.com Thu Oct 6 09:38:04 2005 From: dhowells at redhat.com (David Howells) Date: Thu, 06 Oct 2005 10:38:04 +0100 Subject: [redhat-lspp] LSPP work items In-Reply-To: References: <200510041746.52600.sgrubb@redhat.com> <20051005191214.GA12239@w-m-p.com> <20051005192025.GB16352@shell0.pdx.osdl.net> <20051005193117.GB12239@w-m-p.com> Message-ID: <21594.1128591484@warthog.cambridge.redhat.com> James Morris wrote: > Not sure how feasible or useful it would be to add a boot parameter for > the key subsystem -- it introduces a system call, for example. That could be done reasonably easily I think; it'd just slow things down a touch. The three system calls and many of the interface functions would have to detect the fact that the key management code is disabled and return an appropriate error just in case something tried to use them. David From dhowells at redhat.com Thu Oct 6 09:47:39 2005 From: dhowells at redhat.com (David Howells) Date: Thu, 06 Oct 2005 10:47:39 +0100 Subject: [redhat-lspp] LSPP work items In-Reply-To: <20051005201503.GC12239@w-m-p.com> References: <20051005201503.GC12239@w-m-p.com> <200510041746.52600.sgrubb@redhat.com> <20051005191214.GA12239@w-m-p.com> <20051005192025.GB16352@shell0.pdx.osdl.net> <20051005193117.GB12239@w-m-p.com> Message-ID: <21812.1128592059@warthog.cambridge.redhat.com> Klaus Weidner wrote: > Another option would be to turn it into a loadable module, this would > probably be a more generally useful change than the boot time switch. I > guess the system calls could be implemented as stubs that check for > enablement / module presence and then call the real implementation, or > ENOSYS if not available? That would not really be feasible: (1) Each task_struct and signal_struct carry keyrings around that need to be dealt with by fork/clone/execve/exit. (2) The user_struct carries around common keyrings that need to be dealt with by instantiation of a user newly visible to the kernel and a user that's being discarded because it's no longer in active use. (3) The session keyring is inherited across fork and clone, and new session keyrings may be imposed as desired (eg: by PAM). You'd have to work out the inheritance pattern upon the module being loaded and subscribe processes to certain keyrings. (4) Implemented system calls in modules tends to get one crisped. David From dhowells at redhat.com Thu Oct 6 10:44:34 2005 From: dhowells at redhat.com (David Howells) Date: Thu, 06 Oct 2005 11:44:34 +0100 Subject: [redhat-lspp] LSPP work items In-Reply-To: References: <200510041746.52600.sgrubb@redhat.com> <20051005191214.GA12239@w-m-p.com> <20051005192025.GB16352@shell0.pdx.osdl.net> <20051005193117.GB12239@w-m-p.com> <20051005201503.GC12239@w-m-p.com> Message-ID: <23122.1128595474@warthog.cambridge.redhat.com> James Morris wrote: > One thing I'm concerned at, which I suspect you may be, is that if we > include key objects in LSPP, then we may need to go further than just > "access to objects" and start looking at the semantics of the keys, > effectively implementing crypto policy. e.g. it may not just be enough to > have labels assigned to keys, but to have those labels reflect the content > of the keys (e.g. "high_assurance_cipher_t"). My main idea how to use key labelling is to label keys intended for specific targets. For instance, with AFS there is a collection of standard utilities which use AFS keys to access the various AFS servers. These run in userspace and, reasonably, want to be able to read your AFS keys. However, you may not want it to be possible to use such as keyctl, for example, to just dump the key contents. So what you'd do is label your AFS keys as only being able to be read by AFS services, such as the AFS kernel module or the AFS utility programs. > In any case, if there are no significant in-tree users of the key > subsystem, then I'm not sure we need to include this subsystem in the LSPP > evaluation. There are no in-kernel users of this facility yet. > David: can you explain who is using this code Keys are being looked at for use with OpenAFS, NFSv4, eCryptFS, Reiser4, Kerberos and SSH that I know of. > and whether you think it could be made modular? No. It's too well linked into the core code and it needs to follow the session inheritance pattern (see previous email). David From sds at tycho.nsa.gov Thu Oct 6 11:56:04 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 06 Oct 2005 07:56:04 -0400 Subject: [redhat-lspp] zip & unzip - restoring labels? In-Reply-To: References: Message-ID: <1128599764.15836.4.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2005-10-05 at 17:39 -0500, Debora Velarde wrote: > I've been working on adding support for extended attributes, including > "security.selinux" to zip & unzip. > > With MLS, a user should not be allowed to downgrade information, but > upgrading it is okay. > Therefore, I think the default behavior for zip and unzip should be to NOT > try to restore the labels. I agree. > For example, if a user zips up 3 files: 2 "unclassified" and 1 "top > secret", then the resulting archive should be "top secret" (the least > upper bound the process can be running at in order to zip up all 3 files). > If that archive is moved to a different system, then it should also be > "top secret" on the 2nd system. > If that archive is unzipped on the 2nd system, all the extracted files > will also be "top secret" because that is the level the process must be at > in order to unzip the archive. When you say the "archive" should be "top secret", do you just mean the label on the archive file, or some label stored in the archive itself? If the former, then it should be handled automatically based on the label of the process creating the archive, without any action by zip itself, because the process would have to be "top secret" to read the "top secret" files in the first place; thus, any files it creates will also be "top secret". Likewise, if the label on the archive file is preserved via whatever mechanism is used to transfer it to the recipient, then the process that runs unzip would likewise have to be "top secret" to read the archive. Thus, what you describe above doesn't require any special logic in zip or unzip. > Because we don't want someone to unintentionally downgrade information > from "top secret" to "unclassified", unzip should only attempt to restore > the labels if specified with a command line option. -- Stephen Smalley National Security Agency From sgrubb at redhat.com Thu Oct 6 12:40:57 2005 From: sgrubb at redhat.com (Steve Grubb) Date: Thu, 6 Oct 2005 08:40:57 -0400 Subject: [redhat-lspp] LSPP work items In-Reply-To: References: <200510041746.52600.sgrubb@redhat.com> <20051005193117.GB12239@w-m-p.com> Message-ID: <200510060840.57653.sgrubb@redhat.com> On Wednesday 05 October 2005 15:53, James Morris wrote: > > I think it would be worthwhile to add a kernel boot parameter or some > > other runtime switch so that it can be turned off without needing a > > specially built kernel. > > I've added David to the cc list in case he's not on redhat-lspp. > > Not sure how feasible or useful it would be to add a boot parameter for > the key subsystem -- it introduces a system call, for example. This sounds like a bad idea. Are there any other boot parameters that disable a syscall? Why would you also want to disable a feature that is likely to be used to improve security? I think kernel keys qualifies as an object and should be dealt with and not removed. -Steve From William.Roe at gd-ais.com Thu Oct 6 13:22:53 2005 From: William.Roe at gd-ais.com (Roe, William H.) Date: Thu, 6 Oct 2005 09:22:53 -0400 Subject: [redhat-lspp] zip & unzip - restoring labels? Message-ID: Shouldn't an ISSO be allowed to downgrade information? The ability to downgrade seems like a privilege/rule assigned to a user account. William Roe, CISSP, M.S. IA General Dynamics, IMS-EDIS-AIS Technical Engineering Matrix Manager Sr. Lead Software Engineer 410/859-2076 office 443/220-8910 blackberry william.roe at gd-ais.com -----Original Message----- From: redhat-lspp-bounces at redhat.com [mailto:redhat-lspp-bounces at redhat.com] On Behalf Of Debora Velarde Sent: Wednesday, October 05, 2005 6:39 PM To: lspp-list Subject: [redhat-lspp] zip & unzip - restoring labels? I've been working on adding support for extended attributes, including "security.selinux" to zip & unzip. With MLS, a user should not be allowed to downgrade information, but upgrading it is okay. Therefore, I think the default behavior for zip and unzip should be to NOT try to restore the labels. For example, if a user zips up 3 files: 2 "unclassified" and 1 "top secret", then the resulting archive should be "top secret" (the least upper bound the process can be running at in order to zip up all 3 files). If that archive is moved to a different system, then it should also be "top secret" on the 2nd system. If that archive is unzipped on the 2nd system, all the extracted files will also be "top secret" because that is the level the process must be at in order to unzip the archive. Because we don't want someone to unintentionally downgrade information from "top secret" to "unclassified", unzip should only attempt to restore the labels if specified with a command line option. Thoughts? debbie -- redhat-lspp mailing list redhat-lspp at redhat.com https://www.redhat.com/mailman/listinfo/redhat-lspp From William.Roe at gd-ais.com Thu Oct 6 13:29:07 2005 From: William.Roe at gd-ais.com (Roe, William H.) Date: Thu, 6 Oct 2005 09:29:07 -0400 Subject: [redhat-lspp] zip & unzip - restoring labels? Message-ID: Other CMW's just assume the session label level when labels are not present. E.g. Zip, Tar, CD's, etc William Roe, CISSP, M.S. IA General Dynamics, IMS-EDIS-AIS Technical Engineering Matrix Manager Sr. Lead Software Engineer 410/859-2076 office 443/220-8910 blackberry william.roe at gd-ais.com -----Original Message----- From: redhat-lspp-bounces at redhat.com [mailto:redhat-lspp-bounces at redhat.com] On Behalf Of Russell Coker Sent: Thursday, October 06, 2005 1:08 AM To: Klaus Weidner Cc: Debora Velarde; lspp-list Subject: Re: [redhat-lspp] zip & unzip - restoring labels? On Wed, 2005-10-05 at 18:22 -0500, Klaus Weidner wrote: > On Wed, Oct 05, 2005 at 05:39:26PM -0500, Debora Velarde wrote: [snipped why zip as a non-admin should not have MLS support] > Restoring labels can only work for an administrator, similar to how > tar only restores user IDs when run as root. It would be the admin's > responsibility to make sure that the extracted rights make sense. We don't support zip/unzip as backup tools, so it seems to me that we have no LSPP requirements for preserving labels given Debora's analysis of the situation. Whether we want to have zip/unzip support SE Linux contexts (for DT functionality) seems a separate issue. I guess that DT support in tools such as zip/unzip is not a LSPP requirement. -- redhat-lspp mailing list redhat-lspp at redhat.com https://www.redhat.com/mailman/listinfo/redhat-lspp From William.Roe at gd-ais.com Thu Oct 6 13:42:40 2005 From: William.Roe at gd-ais.com (Roe, William H.) Date: Thu, 6 Oct 2005 09:42:40 -0400 Subject: [redhat-lspp] LSPP work items Message-ID: Has there been any thought of supporting DFS that relied on Kerberos and which originally shipped with DCE. I understand that Windows, which now supports kerberos, is also supporting DFS. This could go a long way toward interoperability. Bill William Roe, CISSP, M.S. IA General Dynamics, IMS-EDIS-AIS Technical Engineering Matrix Manager Sr. Lead Software Engineer 410/859-2076 office 443/220-8910 blackberry william.roe at gd-ais.com -----Original Message----- From: redhat-lspp-bounces at redhat.com [mailto:redhat-lspp-bounces at redhat.com] On Behalf Of David Howells Sent: Thursday, October 06, 2005 6:45 AM To: James Morris Cc: David Howells; Chris Wright; Klaus Weidner; Steve Grubb; lspp-list Subject: Re: [redhat-lspp] LSPP work items James Morris wrote: > One thing I'm concerned at, which I suspect you may be, is that if we > include key objects in LSPP, then we may need to go further than just > "access to objects" and start looking at the semantics of the keys, > effectively implementing crypto policy. e.g. it may not just be > enough to have labels assigned to keys, but to have those labels > reflect the content of the keys (e.g. "high_assurance_cipher_t"). My main idea how to use key labelling is to label keys intended for specific targets. For instance, with AFS there is a collection of standard utilities which use AFS keys to access the various AFS servers. These run in userspace and, reasonably, want to be able to read your AFS keys. However, you may not want it to be possible to use such as keyctl, for example, to just dump the key contents. So what you'd do is label your AFS keys as only being able to be read by AFS services, such as the AFS kernel module or the AFS utility programs. > In any case, if there are no significant in-tree users of the key > subsystem, then I'm not sure we need to include this subsystem in the > LSPP evaluation. There are no in-kernel users of this facility yet. > David: can you explain who is using this code Keys are being looked at for use with OpenAFS, NFSv4, eCryptFS, Reiser4, Kerberos and SSH that I know of. > and whether you think it could be made modular? No. It's too well linked into the core code and it needs to follow the session inheritance pattern (see previous email). David -- redhat-lspp mailing list redhat-lspp at redhat.com https://www.redhat.com/mailman/listinfo/redhat-lspp From dhowells at redhat.com Thu Oct 6 09:13:50 2005 From: dhowells at redhat.com (David Howells) Date: Thu, 06 Oct 2005 10:13:50 +0100 Subject: [redhat-lspp] LSPP work items In-Reply-To: References: <200510041746.52600.sgrubb@redhat.com> <20051005191214.GA12239@w-m-p.com> <20051005192025.GB16352@shell0.pdx.osdl.net> <20051005193117.GB12239@w-m-p.com> <20051005201503.GC12239@w-m-p.com> Message-ID: <20874.1128590030@warthog.cambridge.redhat.com> James Morris wrote: > David: can you explain who is using this code and whether you think it > could be made modular? I missed the first part of this conversation, and can't get at it in the archives until I manage to subscribe myself to the list. David From William.Roe at gd-ais.com Thu Oct 6 13:57:27 2005 From: William.Roe at gd-ais.com (Roe, William H.) Date: Thu, 6 Oct 2005 09:57:27 -0400 Subject: [redhat-lspp] zip & unzip - restoring labels? Message-ID: I also want to assert that his has to be an auditable event. E.g. if the downgrade privilege is given to an isso role, downgrades events are in the audit, and when the auditor logs into that role with a rule/privilege to read the audits -- not just write -- the auditor will audit those events. The ISSO role role should not have audit read implicitly turned on. In less complex environments one person could be assiged both auditor and isso roles. Conversely in highly secure environments the roles different people are in these roles and provides and implementation of the two person rule. William Roe, CISSP, M.S. IA General Dynamics, IMS-EDIS-AIS Technical Engineering Matrix Manager Sr. Lead Software Engineer 410/859-2076 office 443/220-8910 blackberry william.roe at gd-ais.com -----Original Message----- From: redhat-lspp-bounces at redhat.com [mailto:redhat-lspp-bounces at redhat.com] On Behalf Of Roe, William H. Sent: Thursday, October 06, 2005 9:23 AM To: Debora Velarde; lspp-list Subject: RE: [redhat-lspp] zip & unzip - restoring labels? Shouldn't an ISSO be allowed to downgrade information? The ability to downgrade seems like a privilege/rule assigned to a user account. William Roe, CISSP, M.S. IA General Dynamics, IMS-EDIS-AIS Technical Engineering Matrix Manager Sr. Lead Software Engineer 410/859-2076 office 443/220-8910 blackberry william.roe at gd-ais.com -----Original Message----- From: redhat-lspp-bounces at redhat.com [mailto:redhat-lspp-bounces at redhat.com] On Behalf Of Debora Velarde Sent: Wednesday, October 05, 2005 6:39 PM To: lspp-list Subject: [redhat-lspp] zip & unzip - restoring labels? I've been working on adding support for extended attributes, including "security.selinux" to zip & unzip. With MLS, a user should not be allowed to downgrade information, but upgrading it is okay. Therefore, I think the default behavior for zip and unzip should be to NOT try to restore the labels. For example, if a user zips up 3 files: 2 "unclassified" and 1 "top secret", then the resulting archive should be "top secret" (the least upper bound the process can be running at in order to zip up all 3 files). If that archive is moved to a different system, then it should also be "top secret" on the 2nd system. If that archive is unzipped on the 2nd system, all the extracted files will also be "top secret" because that is the level the process must be at in order to unzip the archive. Because we don't want someone to unintentionally downgrade information from "top secret" to "unclassified", unzip should only attempt to restore the labels if specified with a command line option. Thoughts? debbie -- redhat-lspp mailing list redhat-lspp at redhat.com https://www.redhat.com/mailman/listinfo/redhat-lspp -- redhat-lspp mailing list redhat-lspp at redhat.com https://www.redhat.com/mailman/listinfo/redhat-lspp From rcoker at redhat.com Thu Oct 6 14:03:09 2005 From: rcoker at redhat.com (Russell Coker) Date: Fri, 07 Oct 2005 00:03:09 +1000 Subject: [redhat-lspp] zip & unzip - restoring labels? In-Reply-To: References: Message-ID: <1128607389.3463.120.camel@aeon> On Thu, 2005-10-06 at 09:29 -0400, Roe, William H. wrote: > Other CMW's just assume the session label level when labels are not > present. E.g. Zip, Tar, CD's, etc I think that's what we have to do for Zip files, VFAT/MSDOS file systems, ISO9960 format CDs and lots of other things. Tar is different, not only is it used by a user for collecting files (which seems like they should be without level information based on the discussion on this list) but it's also used by the administrator as a backup tool in which case it should preserve such data. star already has support for preserving SE Linux contexts. I guess for a non-administrative user we want it to be able to preserve the DT information without the level or category fields. To do this it could try to preserve the entire context and then retry the operation with the current process level and categories if the first attempt doesn't succeed. Stephen, what do you think? From rcoker at redhat.com Thu Oct 6 14:50:53 2005 From: rcoker at redhat.com (Russell Coker) Date: Fri, 07 Oct 2005 00:50:53 +1000 Subject: [redhat-lspp] LSPP work items In-Reply-To: <1128546317.3463.96.camel@aeon> References: <200510041746.52600.sgrubb@redhat.com> <1128493633.3463.47.camel@aeon> <200510051649.01679.sgrubb@redhat.com> <1128546317.3463.96.camel@aeon> Message-ID: <1128610253.3463.128.camel@aeon> On Thu, 2005-10-06 at 07:05 +1000, Russell Coker wrote: > > Sort of. What would it set it back to? When it executes .foward > files, > > it needs to set the loginuid so that any actions it performs is > > properly attributed to the owner of that file and not root/mail. > > Anyway the Postfix "local" program performs system operations > (loginuid==0), then operates on behalf of one user (loginuid==501), > then > back to system operations (loginuid==0) then on behalf of another user > (loginuid==502). OK, I've implemented a quick hack of this. My code surely won't be accepted upstream and probably won't be accepted into rawhide as-is, but works well enough for test purposes. I have attached a sample audit.log showing the Procmail execution with the auid logged. allow postfix_local_t self:file rw_file_perms; allow postfix_local_t self:capability audit_control; Making this work requires adding the above lines to Postfix policy (Dan, don't add this to the rawhide policy just yet, we may change our design plans). The patch for Postfix is named "diff", it's against version 2.2.5-1 (latest rawhide). Are we planning to do the same for other MTAs or are we making Postfix the only supported MTA for LSPP? -------------- next part -------------- A non-text attachment was scrubbed... Name: audit.log Type: text/x-log Size: 1834 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: diff Type: text/x-patch Size: 2130 bytes Desc: not available URL: From dvelarde at us.ibm.com Thu Oct 6 15:01:15 2005 From: dvelarde at us.ibm.com (Debora Velarde) Date: Thu, 6 Oct 2005 10:01:15 -0500 Subject: [redhat-lspp] zip & unzip - restoring labels? In-Reply-To: <1128599764.15836.4.camel@moss-spartans.epoch.ncsc.mil> Message-ID: > > When you say the "archive" should be "top secret", do you just mean the > label on the archive file, or some label stored in the archive itself? The label on the archive file > If the former, then it should be handled automatically based on the > label of the process creating the archive, without any action by zip > itself, because the process would have to be "top secret" to read the > "top secret" files in the first place; thus, any files it creates will > also be "top secret". Right, that's what I was thinking. > Likewise, if the label on the archive file is > preserved via whatever mechanism is used to transfer it to the > recipient, then the process that runs unzip would likewise have to be > "top secret" to read the archive. Yes, exactly. > Thus, what you describe above doesn't > require any special logic in zip or unzip. Correct. It seems as though the default behavior should be to act just as zip/unzip does now. Restoring labels should be an option that must be explicitly passed in by the admin or user that has the authority to restore the labels. From sds at tycho.nsa.gov Thu Oct 6 15:03:46 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 06 Oct 2005 11:03:46 -0400 Subject: [redhat-lspp] zip & unzip - restoring labels? In-Reply-To: References: Message-ID: <1128611026.15836.94.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-10-06 at 10:01 -0500, Debora Velarde wrote: > Correct. It seems as though the default behavior should be to act just as > zip/unzip does now. > Restoring labels should be an option that must be explicitly passed in by > the admin or user that has the authority to restore the labels. Yes, agreed, and that is consistent with star I believe (you have to explicitly specify options to preserve attributes both on the creation side and on the extraction side). Only question is whether you should introduce a new option or just make this behavior conditional on the existing -X option that is used for preserving uid/gid for unzip. -- Stephen Smalley National Security Agency From jmorris at redhat.com Thu Oct 6 15:26:37 2005 From: jmorris at redhat.com (James Morris) Date: Thu, 6 Oct 2005 11:26:37 -0400 (EDT) Subject: [redhat-lspp] LSPP work items In-Reply-To: <21594.1128591484@warthog.cambridge.redhat.com> References: <200510041746.52600.sgrubb@redhat.com> <20051005191214.GA12239@w-m-p.com> <20051005192025.GB16352@shell0.pdx.osdl.net> <20051005193117.GB12239@w-m-p.com> <21594.1128591484@warthog.cambridge.redhat.com> Message-ID: On Thu, 6 Oct 2005, David Howells wrote: > James Morris wrote: > > > Not sure how feasible or useful it would be to add a boot parameter for > > the key subsystem -- it introduces a system call, for example. > > That could be done reasonably easily I think; it'd just slow things down a > touch. > > The three system calls and many of the interface functions would have to > detect the fact that the key management code is disabled and return an > appropriate error just in case something tried to use them. Note that boot params are not viable on all architectures (s390?), so to make this certifiable across all architectures, this would need to be a runtime disable (during early userspace), which we've had to do with SELinux. - James -- James Morris From sgrubb at redhat.com Thu Oct 6 15:30:14 2005 From: sgrubb at redhat.com (Steve Grubb) Date: Thu, 6 Oct 2005 11:30:14 -0400 Subject: [redhat-lspp] LSPP work items In-Reply-To: <1128610253.3463.128.camel@aeon> References: <200510041746.52600.sgrubb@redhat.com> <1128546317.3463.96.camel@aeon> <1128610253.3463.128.camel@aeon> Message-ID: <200510061130.14573.sgrubb@redhat.com> On Thursday 06 October 2005 10:50, Russell Coker wrote: > OK, I've implemented a quick hack of this. ?My code surely won't be > accepted upstream and probably won't be accepted into rawhide as-is, but > works well enough for test purposes. Thanks Russell. I think they would want some #ifdef to allow compilation to proceed where loginuid is not supported. If upstream is uninterested, we can carry it as a patch. > I have attached a sample audit.log showing the Procmail execution with > the auid logged. > > allow postfix_local_t self:file rw_file_perms; > allow postfix_local_t self:capability audit_control; I really hate that changing the loginuid means that they have the ability to write rules. > The patch for Postfix is named "diff", it's against version 2.2.5-1 > (latest rawhide). There are a couple nits, should use uid_t. and return -2 if get_login_uid fails. Right now it returns 0 on failure which is a normal acct. -1 means the loginuid of postfix is unset and this is normal for anything started by init. Generally, the rule is that if you cannot attribute the actions to the real user, the action must be prevented. That means failure to get/set loginuid would require the attempted delivery to fail. > Are we planning to do the same for other MTAs or are we making Postfix > the only supported MTA for LSPP? That would be nice. We (Red Hat) have configured other entry point programs that are not part of any security target to do the right thing. Examples are gdm, kdm, and xdm. -Steve From rcoker at redhat.com Thu Oct 6 21:32:55 2005 From: rcoker at redhat.com (Russell Coker) Date: Fri, 07 Oct 2005 07:32:55 +1000 Subject: [redhat-lspp] mail servers - was LSPP work items In-Reply-To: <200510061130.14573.sgrubb@redhat.com> References: <200510041746.52600.sgrubb@redhat.com> <1128546317.3463.96.camel@aeon> <1128610253.3463.128.camel@aeon> <200510061130.14573.sgrubb@redhat.com> Message-ID: <1128634375.3463.139.camel@aeon> On Thu, 2005-10-06 at 11:30 -0400, Steve Grubb wrote: > On Thursday 06 October 2005 10:50, Russell Coker wrote: > > OK, I've implemented a quick hack of this. My code surely won't be > > accepted upstream and probably won't be accepted into rawhide as-is, but > > works well enough for test purposes. > > Thanks Russell. I think they would want some #ifdef to allow compilation to > proceed where loginuid is not supported. If upstream is uninterested, we can > carry it as a patch. Why would we want this as a ifdef? We can easily have the code simply not run if it doesn't exist. I can't imagine anyone wanting two binary copies of Postfix for this! I can make the code check for the presence of the file and simply do nothing if it doesn't exist. > > I have attached a sample audit.log showing the Procmail execution with > > the auid logged. > > > > allow postfix_local_t self:file rw_file_perms; > > allow postfix_local_t self:capability audit_control; > > I really hate that changing the loginuid means that they have the ability to > write rules. Same here. Can things be changed? > > The patch for Postfix is named "diff", it's against version 2.2.5-1 > > (latest rawhide). > > There are a couple nits, should use uid_t. and return -2 if get_login_uid > fails. Right now it returns 0 on failure which is a normal acct. -1 means the > loginuid of postfix is unset and this is normal for anything started by init. -1 is reserved for the default value. It will be 0 or some positive number if the administrator has restarted the daemon - I have been wondering if a daemon should transition to loginuid==0 on restart, it would be easy to have /sbin/service on Red Hat do "echo -1 >> /proc/self/loginuid" and change run_init for Debian and the Gentoo daemon start program. 65524 (-2 in unsigned short) is used for nfsnobody, I believe that there have been bugs on some platforms where -2 in unsigned long was used for nfsnobody. Maybe we should use -3 just in case? I agree about uid_t in a general concept but wasn't sure about architecture specific issues and used unsigned long as a quick hack that works. > Generally, the rule is that if you cannot attribute the actions to the real > user, the action must be prevented. That means failure to get/set loginuid > would require the attempted delivery to fail. OK. So if loginuid does not exist (stat gives ENOENT) then we keep running without it, if it's EACCESS or some other error then we abort. > > Are we planning to do the same for other MTAs or are we making Postfix > > the only supported MTA for LSPP? > > That would be nice. We (Red Hat) have configured other entry point programs > that are not part of any security target to do the right thing. Examples are > gdm, kdm, and xdm. OK. I'll own the LSPP MTA issues from the Red Hat side in terms of loginuid and also improvements to policy and supporting code (EG getting something better than a single procmail_t domain for delivery). I'll target the RHEL feature list first, and then Fedora Core. I'll also do something with Exim. From sgrubb at redhat.com Thu Oct 6 21:48:15 2005 From: sgrubb at redhat.com (Steve Grubb) Date: Thu, 6 Oct 2005 17:48:15 -0400 Subject: [redhat-lspp] mail servers - was LSPP work items In-Reply-To: <1128634375.3463.139.camel@aeon> References: <200510041746.52600.sgrubb@redhat.com> <200510061130.14573.sgrubb@redhat.com> <1128634375.3463.139.camel@aeon> Message-ID: <200510061748.15316.sgrubb@redhat.com> On Thursday 06 October 2005 17:32, Russell Coker wrote: > > I think they would want some #ifdef to allow compilation > > to proceed where loginuid is not supported. If upstream is uninterested, > > we can carry it as a patch. > > Why would we want this as a ifdef? People on BSD might not want the performance hit. I'm thinking of what you might want to do to get it upstream. > > > allow postfix_local_t self:file rw_file_perms; > > > allow postfix_local_t self:capability audit_control; > > > > I really hate that changing the loginuid means that they have the ability > > to write rules. > > Same here. ?Can things be changed? Possibly. There was a long discussion about this last Jan/feb on linux-audit mail list. Maybe Casey or Stephen remembers how it went. I think it is wrong from the point of view that the ability to set the loginuid and hence misdirect the responsible party for some action is not the same as being able to load and delete rules. Fixing this likely requires taking another capability bit. I think the linux kernel is about out of those. > > > The patch for Postfix is named "diff", it's against version 2.2.5-1 > > > (latest rawhide). > > > > There are a couple nits, should use uid_t. and return -2 if get_login_uid > > fails. Right now it returns 0 on failure which is a normal acct. -1 means > > the loginuid of postfix is unset and this is normal for anything started > > by init. > > -1 is reserved for the default value. huh? -1 in the loginuid attribute means that its unset. This is normal for any process started from init. > It will be 0 or some positive number if the administrator has restarted the > daemon Yes. > - I have been wondering if a daemon should transition to loginuid==0 on > restart, No. If an admin restarted the daemon, this might be forensic evidence that we want to keep. Its working fine as is. > it would be easy to have /sbin/service on Red Hat do "echo -1 >> /proc/self/loginuid" and change run_init for Debian and the > Gentoo daemon start program. no. > 65524 (-2 in unsigned short) is used for nfsnobody, I believe that there > have been bugs on some platforms where -2 in unsigned long was used for > nfsnobody. ?Maybe we should use -3 just in case? Sure. Just want to make sure that we have a unique value to see when there was a failure as opposed to setting it to the wrong thing. > > Generally, the rule is that if you cannot attribute the actions to the > > real user, the action must be prevented. That means failure to get/set > > loginuid would require the attempted delivery to fail. > > OK. ?So if loginuid does not exist (stat gives ENOENT) then we keep > running without it, if it's EACCESS or some other error then we abort. Yes. There are people that build their own kernels and we have to let them run unimpeded if they don't have the auditing system compiled in. Thanks, -Steve From dvelarde at us.ibm.com Thu Oct 6 22:02:55 2005 From: dvelarde at us.ibm.com (Debora Velarde) Date: Thu, 6 Oct 2005 17:02:55 -0500 Subject: [redhat-lspp] zip & unzip - restoring labels? In-Reply-To: <1128611026.15836.94.camel@moss-spartans.epoch.ncsc.mil> Message-ID: Stephen Smalley wrote on 10/06/2005 10:03:46 AM: > On Thu, 2005-10-06 at 10:01 -0500, Debora Velarde wrote: > > Correct. It seems as though the default behavior should be to act just as > > zip/unzip does now. > > Restoring labels should be an option that must be explicitly passed in by > > the admin or user that has the authority to restore the labels. > > Yes, agreed, and that is consistent with star I believe (you have to > explicitly specify options to preserve attributes both on the creation > side and on the extraction side). > > Only question is whether you should introduce a new option or just make > this behavior conditional on the existing -X option that is used for > preserving uid/gid for unzip. For zip, should the default behavior be to go ahead and zip up the extended attributes info? Or should that only be done if specified with an option? If the former, then I could add it to the '-X' option "-X Do not save extra file attributes (Extended Attributes on OS/2, uid/gid and file times on Unix)." Otherwise, zip would need a new option. For unzip, I favor creating a new option in case the admin wants to restore the uid/gid but not the labels. Users can always pass in multiple options. I'm leaning towards 'E' which is not currently defined in zip or unzip on Linux/Unix systems. Any opinions? debbie From rcoker at redhat.com Thu Oct 6 22:21:10 2005 From: rcoker at redhat.com (Russell Coker) Date: Fri, 07 Oct 2005 08:21:10 +1000 Subject: [redhat-lspp] zip & unzip - restoring labels? In-Reply-To: <1128611026.15836.94.camel@moss-spartans.epoch.ncsc.mil> References: <1128611026.15836.94.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1128637270.3463.149.camel@aeon> On Thu, 2005-10-06 at 11:03 -0400, Stephen Smalley wrote: > On Thu, 2005-10-06 at 10:01 -0500, Debora Velarde wrote: > > Correct. It seems as though the default behavior should be to act just as > > zip/unzip does now. > > Restoring labels should be an option that must be explicitly passed in by > > the admin or user that has the authority to restore the labels. > > Yes, agreed, and that is consistent with star I believe (you have to > explicitly specify options to preserve attributes both on the creation > side and on the extraction side). Here is how star currently works in Fedora: To create a star archive with xattr data (including SE Linux contexts): star -xattr -H=exustar -c -f file.tar files To extract an archive including xattrs: star -x -f file.tar Also in all aspects of it's command-line interface star does not distinguish between SE Linux contexts, ACLs, and user XATTRs. In it's internal operation it has special-case handling for SE Linux contexts, it uses /proc/self/attr/fscreate. I'm not sure if it's even possible to use star to extract an star archive in exustar format and not preserve xattrs. It seems that if you have an archive with SE Linux contexts and you don't want to apply them on extraction then you use GNU tar (which has no support for XATTRs and just ignores that data) to extract the archive. If you use star to extract a file which has SE Linux contexts that can not be written by the tar process then the file is skipped (but other files in the same archive are created). So I guess we need to revisit the star patch to add some more options. Specifically we want to treat SE Linux contexts separately to other xattrs and allow creation of archives with xattrs other than SE Linux contexts as well as archive extraction that ignores the contexts. Volunteers? From chanson at TrustedCS.com Thu Oct 6 22:24:59 2005 From: chanson at TrustedCS.com (Chad Hanson) Date: Thu, 6 Oct 2005 18:24:59 -0400 Subject: [redhat-lspp] zip & unzip - restoring labels? Message-ID: <36282A1733C57546BE392885C0618592CE50B2@chaos.tcs.tcs-sec.com> > > For zip, should the default behavior be to go ahead and zip up the > extended attributes info? I would suggest the default is to not save the attribute info, thus preserving compatibility. I would use the new option to save the security attributes. > Or should that only be done if specified with an option? > If the former, then I could add it to the '-X' option > "-X Do not save extra file attributes (Extended > Attributes on > OS/2, uid/gid and file times on Unix)." > Otherwise, zip would need a new option. > > For unzip, I favor creating a new option in case the admin wants to > restore the uid/gid but not the labels. An option to ignore the labels isn't desired as you are then performing an upgrade/downgrade. If a context exists, it should be used in the restore. -Chad From dvelarde at us.ibm.com Thu Oct 6 22:32:03 2005 From: dvelarde at us.ibm.com (Debora Velarde) Date: Thu, 6 Oct 2005 17:32:03 -0500 Subject: [redhat-lspp] zip & unzip - restoring labels? In-Reply-To: <36282A1733C57546BE392885C0618592CE50B2@chaos.tcs.tcs-sec.com> Message-ID: Chad Hanson wrote on 10/06/2005 05:24:59 PM: > > > > > For zip, should the default behavior be to go ahead and zip up the > > extended attributes info? > > I would suggest the default is to not save the attribute info, thus > preserving compatibility. I would use the new option to save the security > attributes. OK. I can also see that we wouldn't want to use up more space or decrease performance of the default behavior if the attribute info isn't going to be used. > An option to ignore the labels isn't desired as you are then performing an > upgrade/downgrade. Would be an upgrade. > If a context exists, it should be used in the restore. We wouldn't want an admin to unintentionally downgrade information. Therefore, it has to be explicitly passed in at the time of unzip. From dwalsh at redhat.com Fri Oct 7 00:12:05 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 06 Oct 2005 20:12:05 -0400 Subject: [redhat-lspp] zip & unzip - restoring labels? In-Reply-To: References: Message-ID: <4345BD55.5070205@redhat.com> Debora Velarde wrote: > Stephen Smalley wrote on 10/06/2005 10:03:46 AM: > > >> On Thu, 2005-10-06 at 10:01 -0500, Debora Velarde wrote: >> >>> Correct. It seems as though the default behavior should be to act >>> > just as > >>> zip/unzip does now. >>> Restoring labels should be an option that must be explicitly passed in >>> > by > >>> the admin or user that has the authority to restore the labels. >>> >> Yes, agreed, and that is consistent with star I believe (you have to >> explicitly specify options to preserve attributes both on the creation >> side and on the extraction side). >> >> Only question is whether you should introduce a new option or just make >> this behavior conditional on the existing -X option that is used for >> preserving uid/gid for unzip. >> > > For zip, should the default behavior be to go ahead and zip up the > extended attributes info? > Or should that only be done if specified with an option? > If the former, then I could add it to the '-X' option > "-X Do not save extra file attributes (Extended Attributes on > OS/2, uid/gid and file times on Unix)." > Otherwise, zip would need a new option. > > For unzip, I favor creating a new option in case the admin wants to > restore the uid/gid but not the labels. > Users can always pass in multiple options. > I'm leaning towards 'E' which is not currently defined in zip or unzip on > Linux/Unix systems. > > Why not -Z since that is used in most apps to deal with selinux context. > Any opinions? > debbie > > -- > redhat-lspp mailing list > redhat-lspp at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-lspp > -- From jmorris at redhat.com Fri Oct 7 02:37:57 2005 From: jmorris at redhat.com (James Morris) Date: Thu, 6 Oct 2005 22:37:57 -0400 (EDT) Subject: [redhat-lspp] LSPP work items In-Reply-To: <21594.1128591484@warthog.cambridge.redhat.com> References: <200510041746.52600.sgrubb@redhat.com> <20051005191214.GA12239@w-m-p.com> <20051005192025.GB16352@shell0.pdx.osdl.net> <20051005193117.GB12239@w-m-p.com> <21594.1128591484@warthog.cambridge.redhat.com> Message-ID: On Thu, 6 Oct 2005, David Howells wrote: > James Morris wrote: > > > Not sure how feasible or useful it would be to add a boot parameter for > > the key subsystem -- it introduces a system call, for example. > > That could be done reasonably easily I think; it'd just slow things down a > touch. > > The three system calls and many of the interface functions would have to > detect the fact that the key management code is disabled and return an > appropriate error just in case something tried to use them. Ok, the issue now is whether it's acceptable to implement a boot parameter, given that i-series machines don't support them, and thus may not be able to run the LSPP certified configuration if we use a boot parameter to disable the key subsystem. Perhaps someone from IBM could comment. - James -- James Morris From rcoker at redhat.com Fri Oct 7 04:01:09 2005 From: rcoker at redhat.com (Russell Coker) Date: Fri, 07 Oct 2005 14:01:09 +1000 Subject: [redhat-lspp] MLS email - worth doing? Message-ID: <1128657669.3463.180.camel@aeon> I've been thinking about the issue of labeled email. Previous discussions in this regard has been based on the MTA tracking the security context of the message through all operations which would mean adding an extra meta-data field to all structures that deal with a message (heaps of work and pain). One of the ASF people who was working on JAME (Java Apache Mail something) liked this idea but ended up not doing any code (this was several years ago, I'm sure that he would have released something by now if he was going to do so). However it seems that a better option is to have the process that receives the message (be it a binary named "sendmail" or a process listening on port 25) put an extra header in the message describing it's security context. Those programs already have code to add extra headers and storing an arbitrary set of headers is the standard operation of all MTA components. So we would want the process receiving the message to put a header in (in the case of Postfix it's "smtpd" for network connections and "postdrop" or "sendmail" for locally sourced email). Then the delivery process (in the case of Postfix it's named "local") would do the appropriate delivery mechanism. In the basic case it would involve running procmail with the appropriate context. There are three issues related to procmail and SE Linux support: 1) Running it in the role $ROLE_r and domain $ROLE_procmail_t. Easy to do, put something like domain_auto_trans(mta_delivery_agent, $1_home_dir_t, $1_procmail_t) in mta_macros.te and then do checks equivalent to what crond does. 2) Getting the correct level. One way of doing this would be to have a procmail config file for each supported level. The MTA could run procmail at the appropriate level and it could then (without knowing much about MLS) try reading config files in order of level. So for example if procmail is run at "secret" level then it would try unsuccessfully to read config files for "unclassified" and "classified" before trying to read the file for "secret". If there was no config file for "secret" then it would look for a config file for "top secret". If a user is not expecting to receive "secret" email then the mail would automatically be upgraded to "top secret", if the user has no config file for that (EG they only have "classified" clearance) then the mail would bounce. 3) Categories. Supporting all combinations of categories is something I don't know how to address. If someone has Procmail configurations for category combinations "c0,c2" and "c0,c3" then what do we do with a message that is classified with category "c0"? Obviously delivery requires upgrading it, but which of the two equally appealing options should be taken? I guess we could have an ordered list of Procmail config files and it could just try them in order and use the first one it can read. The next thing is bounces. A large portion of bounces do not go to the originating user. Therefore it will be quite common for a bounce to be directed to a user who has no clearance to receive it, and thus MLS support in the MTA will significantly increase the incidence of double-bounces. Not sure what we might have to do in regard to this. So is MLS labeled email regarded as desirable? Apart from the issue of categories it's not that difficult to do. I'm speaking at a conference in a couple of weeks so I won't be able to get the coding for this done until at least the end of the month. It's probably about a week's work for a first-cut at doing all this in Postfix. From dhowells at redhat.com Fri Oct 7 10:00:33 2005 From: dhowells at redhat.com (David Howells) Date: Fri, 07 Oct 2005 11:00:33 +0100 Subject: [redhat-lspp] LSPP work items In-Reply-To: References: <200510041746.52600.sgrubb@redhat.com> <20051005191214.GA12239@w-m-p.com> <20051005192025.GB16352@shell0.pdx.osdl.net> <20051005193117.GB12239@w-m-p.com> <21594.1128591484@warthog.cambridge.redhat.com> Message-ID: <23146.1128679233@warthog.cambridge.redhat.com> James Morris wrote: > Ok, the issue now is whether it's acceptable to implement a boot > parameter, given that i-series machines don't support them, Yes they do, eg: echo "root=LABEL=/1" > /proc/iSeries/mf/A/cmdline David From jmorris at redhat.com Fri Oct 7 14:40:03 2005 From: jmorris at redhat.com (James Morris) Date: Fri, 7 Oct 2005 10:40:03 -0400 (EDT) Subject: [redhat-lspp] LSPP work items In-Reply-To: <23146.1128679233@warthog.cambridge.redhat.com> References: <200510041746.52600.sgrubb@redhat.com> <20051005191214.GA12239@w-m-p.com> <20051005192025.GB16352@shell0.pdx.osdl.net> <20051005193117.GB12239@w-m-p.com> <21594.1128591484@warthog.cambridge.redhat.com> <23146.1128679233@warthog.cambridge.redhat.com> Message-ID: On Fri, 7 Oct 2005, David Howells wrote: > James Morris wrote: > > > Ok, the issue now is whether it's acceptable to implement a boot > > parameter, given that i-series machines don't support them, > > Yes they do, eg: > > echo "root=LABEL=/1" > /proc/iSeries/mf/A/cmdline I've been told that this not useful when booting, and that "you have to set them before you reboot and have no way to override or change them" - James -- James Morris From dhowells at redhat.com Fri Oct 7 14:44:18 2005 From: dhowells at redhat.com (David Howells) Date: Fri, 07 Oct 2005 15:44:18 +0100 Subject: [redhat-lspp] LSPP work items In-Reply-To: References: <200510041746.52600.sgrubb@redhat.com> <20051005191214.GA12239@w-m-p.com> <20051005192025.GB16352@shell0.pdx.osdl.net> <20051005193117.GB12239@w-m-p.com> <21594.1128591484@warthog.cambridge.redhat.com> <23146.1128679233@warthog.cambridge.redhat.com> Message-ID: <21989.1128696258@warthog.cambridge.redhat.com> James Morris wrote: > I've been told that this not useful when booting, and that "you have to > set them before you reboot and have no way to override or change them" I see what you mean. I'm not entirely sure that's true. It might be possible to set it from the control console, but it's not as easy as with yaboot or grub. David From sds at tycho.nsa.gov Fri Oct 7 14:41:04 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 07 Oct 2005 10:41:04 -0400 Subject: [redhat-lspp] LSPP work items In-Reply-To: References: <200510041746.52600.sgrubb@redhat.com> <20051005191214.GA12239@w-m-p.com> <20051005192025.GB16352@shell0.pdx.osdl.net> <20051005193117.GB12239@w-m-p.com> <21594.1128591484@warthog.cambridge.redhat.com> <23146.1128679233@warthog.cambridge.redhat.com> Message-ID: <1128696064.1450.28.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-10-07 at 10:40 -0400, James Morris wrote: > On Fri, 7 Oct 2005, David Howells wrote: > > > James Morris wrote: > > > > > Ok, the issue now is whether it's acceptable to implement a boot > > > parameter, given that i-series machines don't support them, > > > > Yes they do, eg: > > > > echo "root=LABEL=/1" > /proc/iSeries/mf/A/cmdline > > I've been told that this not useful when booting, and that "you have to > set them before you reboot and have no way to override or change them" Note btw that we were specifically told that boot parameters were inadequate for disabling SELinux, which is why we introduced the runtime disable support via selinuxfs that is used by /sbin/init when /etc/selinux/config says to disable it. -- Stephen Smalley National Security Agency From dvelarde at us.ibm.com Fri Oct 7 15:04:33 2005 From: dvelarde at us.ibm.com (Debora Velarde) Date: Fri, 7 Oct 2005 10:04:33 -0500 Subject: [redhat-lspp] zip & unzip - restoring labels? In-Reply-To: <4345BD55.5070205@redhat.com> Message-ID: > Why not -Z since that is used in most apps to deal with selinux context. -Z is an existing option for unzip. From mcthomps at us.ibm.com Fri Oct 7 16:13:40 2005 From: mcthomps at us.ibm.com (Michael C Thompson) Date: Fri, 7 Oct 2005 11:13:40 -0500 Subject: [redhat-lspp] LSPP work items In-Reply-To: Message-ID: > > James Morris wrote: > > > > > Not sure how feasible or useful it would be to add a boot parameter for > > > the key subsystem -- it introduces a system call, for example. > > > > That could be done reasonably easily I think; it'd just slow things down a > > touch. > > > > The three system calls and many of the interface functions would have to > > detect the fact that the key management code is disabled and return an > > appropriate error just in case something tried to use them. > > Note that boot params are not viable on all architectures (s390?), so to > make this certifiable across all architectures, this would need to be a > runtime disable (during early userspace), which we've had to do with > SELinux. I can't speak for any other architectures, but depending on how your s390 is setup, boot params to the kernel are possible. Every s390 I've used have the zOS load grub, which will then bootstrap your linux kernel. So as long as you've got a s390(x) setup in a relatively sane fashion, you can treat it as a standard box from grub forward. Of course, this might not be true for _all_ archs, but I would imagine its a fairly safe bet. [Unless someone wants to expand my knowledge and point to a system that wouldn't?] - Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcoker at redhat.com Mon Oct 10 09:03:16 2005 From: rcoker at redhat.com (Russell Coker) Date: Mon, 10 Oct 2005 19:03:16 +1000 Subject: [redhat-lspp] LSPP test machine Message-ID: <1128934996.4107.33.camel@aeon> Would it be helpful if I setup a LSPP test machine for public access? I could provide administrative access to a small group of trusted people as well as guest access to anyone who wants it. The machine would be hosted on my home cable connection, this makes it very slow for sending data (quite good for ssh sessions but bad for scp). It would however be able to download files from the net at speeds over 300KB/s (so tracking rawhide would be easy and pleasant). The usual caveats of shared servers would apply (don't login with X or auth forwarding, don't trust any files copied from the machine, etc). The machine would also be on the sub-net I reserve for hostile hosts (so you want to get the ssh host key setup correctly and not use a Windows client). If there is a need I could place such a machine in the server room of a friendly company. That would give much higher transmission speeds, lower speeds for receiving data, and a less hostile local network, but if it crashes I couldn't easily fix it (would be annoying if a kernel upgrade goes bad). Let me know what you desire in this regard. From rob.myers at gtri.gatech.edu Mon Oct 10 19:22:24 2005 From: rob.myers at gtri.gatech.edu (Rob Myers) Date: Mon, 10 Oct 2005 15:22:24 -0400 Subject: [redhat-lspp] File Integrity Tests from RBAC In-Reply-To: <4342B9CF.4090302@hp.com> References: <200509291403.36799.sgrubb@redhat.com> <4342ADE8.9000504@hp.com> <200510041250.07500.sgrubb@redhat.com> <4342B9CF.4090302@hp.com> Message-ID: <1128972144.5019.36.camel@rXm-581b.stl.gtri.gatech.edu> On Tue, 2005-10-04 at 13:20 -0400, Linda Knippers wrote: > Steve Grubb wrote: > > On Tuesday 04 October 2005 12:29, Linda Knippers wrote: > > > I'll agree that it should know the files and permissions, but will it > > know the labels and the contents of the config files? > > If the labels and the contents of the config files matter (and > they would, wouldn't they?), then the configuration script would > be verify or set the information at configuration time and then > be able to verify it later. > > > Also, does it need to ensure that the version of the executable > > hasn't been altered? > > To meet FPT_TST.1.3, it probably would. > > > And how does upgrades work? If there is a software update to fix a > > security problem, is the Integrity test suite now broken? > > If only authorized users can install software, including security > updates, then the script could check that the software still matches > what was installed, either at configuration time or with an update, and > still has the appropriate permissions and labels as required > for the LSPP configuration. If the configuration script is > changing permissions or labels, then you'd probably want to re-run > it after any update in case the update reset anything that the > configuration script changed. I have seen systems that use tripwire to meet similar integrity requirements. These systems handle updates and upgrades by procedure: 1. Verify system integrity (tripwire --check) 2. Update or Upgrade 3. Update the integrity database (tripwire --update) for the updated system. This does leave a (small?) window open for any unauthorized changes that may occur during update or upgrade. AFAIK, the GPL version of tripwire does not verify labels. To use tripwire to meet the RBAC/LSPP integrity requirements, a script would have to be written to correctly set labels and permissions, a tripwire policy would have to be written to check the appropriate files, and tripwire would have to be extended to verify labels. Updates and upgrades would still have to be handled by a procedure similar to what I outlined above. While it may not be required for CC evaluation, my preference would be for a configurable tool that a sysadmin could use to verify the integrity of any part of the system. rob. > > -- ljk > > > > -- > redhat-lspp mailing list > redhat-lspp at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-lspp From paul.moore at hp.com Thu Oct 13 16:39:10 2005 From: paul.moore at hp.com (Paul Moore) Date: Thu, 13 Oct 2005 12:39:10 -0400 Subject: [redhat-lspp] HOW-TO: Configuring Fedora Core To Use The MLS SELinux Policy Message-ID: <434E8DAE.2040209@hp.com> On the LSPP development conference call yesterday it came out that there was a need for an updated HOW-TO for converting a normal Fedora system into a Rawhide/Fedora MLS system. For the past several months I have been maintaining a document with step-by-step instructions on doing just that; I'm attaching a copy of that document to this email. I updated the document the last time I installed a MLS system from scratch which was the middle of August, so there may be some *small* changes needed, however, the bulk of the document should be correct. If you run into any problems, or have some corrections/suggestions let me know. -- . paul moore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . paul.moore at hp.com hewlett packard . (603) 884-5056 linux security -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fedora_mls-rhlspp.txt URL: From dwalsh at redhat.com Fri Oct 14 15:07:37 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 14 Oct 2005 11:07:37 -0400 Subject: [redhat-lspp] Rawhide updated to use getseuserbyname for logins. Message-ID: <434FC9B9.4020203@redhat.com> This means that gdm, pam, sshd have been update to use the seusers file to map Linux Users to SELinux Users. (gdm will be there tonight) This means that people can start taking advantage of labeled files on your system and try to create documents with different categories. You can also generate users who will not be allowed to access these files. How does seusers work? A new file /etc/selinux/TYPE/seusers file has been added to all policies. In strict and targeted policy it looks like cat /etc/selinux/targeted/seusers root:root:s0-s0:c0.c255 default:user_u:s0 In MLS cat /etc/selinux/mls/seusers root:root:s0-s15:c0.c255 default:user_u:s0 Most users will map directly to the "default" user which usually gives user_u and Level S0. So most users do not need to change anything. Policy has been updated to support 256 categories and 16 sensitivity levels (for MLS). You may need to change your /etc/mcs.conf file for SystemHigh to reflect this change. Change c127 to c255. You can manipulate the seusers file to change the role/level of individual users on your system. For example if I added a dwalsh "selinux user" on my system and wanted to allow maximum MCS access for dwalsh, I would add an entry of dwalsh:dwalsh:s0-s0:c0.c255 to the seusers file. If I wanted to add a user, bgates, to have limited privs, but allow access to Secret Documents c1 I would add bgates:user_u:s0-s0:c1 (I would also define "s0:c1=Secret" in /etc/mcs.conf) If I do not add a Linux user I get the "default" entry default:user_u:s0 If I wanted all my users do have full MCS privs by default, I could modify the "default" entry to default:user_u:s0-s0:c0.c255 In strict policy you could add an entry like dwalsh:staff_u:s0-s0:c0.c255 Genhomedircon had not been modified yet to read this though :^( Dan -- From rcoker at redhat.com Fri Oct 14 01:06:25 2005 From: rcoker at redhat.com (Russell Coker) Date: Fri, 14 Oct 2005 11:06:25 +1000 Subject: [redhat-lspp] HOW-TO: Configuring Fedora Core To Use The MLS SELinux Policy In-Reply-To: <434E8DAE.2040209@hp.com> References: <434E8DAE.2040209@hp.com> Message-ID: <1129251985.4107.146.camel@aeon> On Thu, 2005-10-13 at 12:39 -0400, Paul Moore wrote: > On the LSPP development conference call yesterday it came out that there There was a conference call? With no agenda and no reminder message I assumed it wasn't happening. What happened? Are there any minutes? > was a need for an updated HOW-TO for converting a normal Fedora system > into a Rawhide/Fedora MLS system. For the past several months I have > been maintaining a document with step-by-step instructions on doing just > that; I'm attaching a copy of that document to this email. I've got a kickstart configuration for doing an automated MLS install. It's on http://www.coker.com.au/selinux/mls/ . From sgrubb at redhat.com Fri Oct 14 17:27:21 2005 From: sgrubb at redhat.com (Steve Grubb) Date: Fri, 14 Oct 2005 13:27:21 -0400 Subject: [redhat-lspp] Rawhide updated to use getseuserbyname for logins. In-Reply-To: <434FC9B9.4020203@redhat.com> References: <434FC9B9.4020203@redhat.com> Message-ID: <200510141327.21385.sgrubb@redhat.com> On Friday 14 October 2005 11:07, Daniel J Walsh wrote: > You can manipulate the seusers file to change the role/level of > individual users on your system. ?For example > if I added a dwalsh "selinux user" on my system and wanted to allow > maximum MCS access for dwalsh, > I would add an entry of > > dwalsh:dwalsh:s0-s0:c0.c255 > to the seusers file. This whole addition sounds like good news. But as for auditability....I think we need an application to do this mapping so that an audit message is generated saying that this user has been assigned to that role/se linux user. We can place a watch on the file, which tells you the file was modified. But I think the information needed is at the user rather than the file level. -Steve From sds at tycho.nsa.gov Fri Oct 14 17:52:23 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 14 Oct 2005 13:52:23 -0400 Subject: [redhat-lspp] Rawhide updated to use getseuserbyname for logins. In-Reply-To: <200510141327.21385.sgrubb@redhat.com> References: <434FC9B9.4020203@redhat.com> <200510141327.21385.sgrubb@redhat.com> Message-ID: <1129312343.3729.21.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-10-14 at 13:27 -0400, Steve Grubb wrote: > On Friday 14 October 2005 11:07, Daniel J Walsh wrote: > > You can manipulate the seusers file to change the role/level of > > individual users on your system. For example > > if I added a dwalsh "selinux user" on my system and wanted to allow > > maximum MCS access for dwalsh, > > I would add an entry of > > > > dwalsh:dwalsh:s0-s0:c0.c255 > > to the seusers file. > > This whole addition sounds like good news. > > But as for auditability....I think we need an application to do this mapping > so that an audit message is generated saying that this user has been assigned > to that role/se linux user. We can place a watch on the file, which tells you > the file was modified. But I think the information needed is at the user > rather than the file level. Ivan is already working on adding support to libsemanage to add/modify the records of the file, and then one can create utilities for this purpose and instrument them for audit. -- Stephen Smalley National Security Agency From ltcgcw at us.ibm.com Fri Oct 14 17:58:40 2005 From: ltcgcw at us.ibm.com (George Wilson) Date: Fri, 14 Oct 2005 12:58:40 -0500 Subject: [redhat-lspp] HOW-TO: Configuring Fedora Core To Use The MLS SELinux Policy In-Reply-To: <1129251985.4107.146.camel@aeon> References: <434E8DAE.2040209@hp.com> <1129251985.4107.146.camel@aeon> Message-ID: <1129312720.31252.44.camel@ea.austin.ibm.com> On Fri, 2005-10-14 at 11:06 +1000, Russell Coker wrote: > On Thu, 2005-10-13 at 12:39 -0400, Paul Moore wrote: > > On the LSPP development conference call yesterday it came out that there > > There was a conference call? With no agenda and no reminder message I > assumed it wasn't happening. > > What happened? Are there any minutes? > > > was a need for an updated HOW-TO for converting a normal Fedora system > > into a Rawhide/Fedora MLS system. For the past several months I have > > been maintaining a document with step-by-step instructions on doing just > > that; I'm attaching a copy of that document to this email. > > I've got a kickstart configuration for doing an automated MLS install. > It's on http://www.coker.com.au/selinux/mls/ . > > -- > redhat-lspp mailing list > redhat-lspp at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-lspp > Apologies to you Russell, and to any others who didn't get a reminder. I sent out a reminder note with agenda last Friday but hadn't sync'd my mutt aliases with evolution. So only some folks got the reminder. I'll be sending out a new repeating notice today. I'll also send a notice to the list w/o details. Debora Velarde has written up some meeting notes. I'll edit and post them today or tomorrow. -- George Wilson IBM Linux Technology Center From chanson at TrustedCS.com Fri Oct 14 21:30:22 2005 From: chanson at TrustedCS.com (Chad Hanson) Date: Fri, 14 Oct 2005 17:30:22 -0400 Subject: [redhat-lspp] License for dev_allocator? Message-ID: <36282A1733C57546BE392885C0618592D39608@chaos.tcs.tcs-sec.com> Hi, Sorry this took so long.... I have attached an updated source RPM with some improved content and a GPL license. -Chad > > > I have a patch for the dev_allocator sources TCS posted to this list a > while back which makes the library/tool a little more useful and fixes a > few problems. However, before I can post the patch I need some > indication from TCS that the dev_allocator sources they posted are now > under an OpenSource license. For various reasons I think a lot of > people on this list would like to see the code open. -------------- next part -------------- A non-text attachment was scrubbed... Name: dev_allocator-0.4-1.src.rpm Type: application/octet-stream Size: 25742 bytes Desc: not available URL: From gcwilson at us.ibm.com Fri Oct 14 23:11:11 2005 From: gcwilson at us.ibm.com (George Wilson) Date: Fri, 14 Oct 2005 18:11:11 -0500 Subject: [redhat-lspp] LSPP Development Telecon 10/12/2005 Minutes Message-ID: 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: From dhowells at redhat.com Mon Oct 17 12:53:56 2005 From: dhowells at redhat.com (David Howells) Date: Mon, 17 Oct 2005 13:53:56 +0100 Subject: [redhat-lspp] Re: [Keyrings] [RFC] Coming key management support improvements In-Reply-To: <5378.1127211442@warthog.cambridge.redhat.com> References: <5378.1127211442@warthog.cambridge.redhat.com> Message-ID: <3014.1129553636@warthog.cambridge.redhat.com> Hi Trond, David Howells wrote: > (3) Make it possible for request_key() to avoid forking and executing > /sbin/request-key when a new key needs to be instantiated, but instead > talk to some already running process to do the honours. > > I'm currently thinking that the way to implement this is to add an extra > operation to the key-type definition so that the key type may override > the default choice of spawning /sbin/request-key. > > This would let NFS use the rpc_pipefs filesystem, for example. > > Alternate default ways of doing things can be added to the main key code > if there's sufficient interest in making them commonly available. I presume this is alright with you, since you haven't objected. David From dwalsh at redhat.com Mon Oct 17 14:38:08 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 17 Oct 2005 10:38:08 -0400 Subject: [redhat-lspp] License for dev_allocator? In-Reply-To: <36282A1733C57546BE392885C0618592D39608@chaos.tcs.tcs-sec.com> References: <36282A1733C57546BE392885C0618592D39608@chaos.tcs.tcs-sec.com> Message-ID: <4353B750.5010604@redhat.com> Chad Hanson wrote: > Hi, > > Sorry this took so long.... I have attached an updated source RPM with some > improved content and a GPL license. > > -Chad > > First pass at clean up of spec file. Why are you creating a separate rpm for libs? I think they should be in the default package. Need to remove the debug line to get it to build here. I am not crazy about the namespace problems on libfloppy and libcdrom. I see a good chance at collision there. Dan >> I have a patch for the dev_allocator sources TCS posted to this list a >> while back which makes the library/tool a little more useful and fixes a >> few problems. However, before I can post the patch I need some >> indication from TCS that the dev_allocator sources they posted are now >> under an OpenSource license. For various reasons I think a lot of >> people on this list would like to see the code open. >> >> ------------------------------------------------------------------------ >> >> -- >> redhat-lspp mailing list >> redhat-lspp at redhat.com >> https://www.redhat.com/mailman/listinfo/redhat-lspp -- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff URL: From dvelarde at us.ibm.com Mon Oct 17 18:14:20 2005 From: dvelarde at us.ibm.com (Debora Velarde) Date: Mon, 17 Oct 2005 13:14:20 -0500 Subject: [redhat-lspp] HOW-TO: Configuring Fedora Core To Use The MLS SELinux Policy In-Reply-To: <1129251985.4107.146.camel@aeon> Message-ID: > I've got a kickstart configuration for doing an automated MLS install. > It's on http://www.coker.com.au/selinux/mls/ . Today is the first time I've tried to access this. I get "Cannot find server". From mra at hp.com Mon Oct 17 23:20:10 2005 From: mra at hp.com (Matt Anderson) Date: Mon, 17 Oct 2005 19:20:10 -0400 Subject: [redhat-lspp] Patch - CUPS local unix sockets Message-ID: <435431AA.2090506@hp.com> Here is my patch for CUPS to force it into using a local Unix socket instead of going over the network. With this patch CUPS will listen on a socket as specified in /etc/cups/cupsd.conf with the Listen directive such as: "Listen /var/run/cupsd.socket". Users get their setting from either the CUPS_SERVER environment variable, or the /etc/cups/client.conf directive ServerName. I tried to leave CUPS as unmodified as possible, which means there are still areas where URIs such as "http://" or "IPP://" are used I am not aware of any URI designation for a Unix socket, but if there is this could be fixed. Despite leaving as much of the original intact, I did have to #ifdef out some chunks of code which peeked into the AF_INET structures in order to make certain decisions. If there are any suggestions for dealing with those routines better I'd love to hear them. Currently this patch, like the two earlier CUPS patches, is based on compile time switches. I'm planning on converting them all into run time options so that there won't be the need for a separate certified CUPS binary. As with before, comments, suggestions, and questions are welcome. -matt -------------- next part -------------- A non-text attachment was scrubbed... Name: cups-ll.patch Type: text/x-patch Size: 87388 bytes Desc: not available URL: From mra at hp.com Tue Oct 18 05:44:48 2005 From: mra at hp.com (Matt Anderson) Date: Tue, 18 Oct 2005 01:44:48 -0400 Subject: [redhat-lspp] Patch - CUPS local unix sockets In-Reply-To: <435431AA.2090506@hp.com> References: <435431AA.2090506@hp.com> Message-ID: <43548BD0.4040007@hp.com> There was a few problems with the initial patch. I had left a copyright in a file that didn't need it, and somehow included a bunch of the CUPS code from scheduler/conf.c in the patch as additions. Attached is an updated version of the patch. -matt -------------- next part -------------- A non-text attachment was scrubbed... Name: cups-ll2.patch Type: text/x-patch Size: 29063 bytes Desc: not available URL: From dhowells at redhat.com Tue Oct 18 12:21:17 2005 From: dhowells at redhat.com (David Howells) Date: Tue, 18 Oct 2005 13:21:17 +0100 Subject: [redhat-lspp] Re: [Keyrings] [RFC] Coming key management support improvements In-Reply-To: <3014.1129553636@warthog.cambridge.redhat.com> References: <3014.1129553636@warthog.cambridge.redhat.com> <5378.1127211442@warthog.cambridge.redhat.com> Message-ID: <25248.1129638077@warthog.cambridge.redhat.com> Hi Trond, > > (3) Make it possible for request_key() to avoid forking and executing > > /sbin/request-key when a new key needs to be instantiated, but instead > > talk to some already running process to do the honours. Can you remind me just why this is necessary? David From sgrubb at redhat.com Tue Oct 18 12:48:23 2005 From: sgrubb at redhat.com (Steve Grubb) Date: Tue, 18 Oct 2005 08:48:23 -0400 Subject: [redhat-lspp] Patch - CUPS local unix sockets In-Reply-To: <43548BD0.4040007@hp.com> References: <435431AA.2090506@hp.com> <43548BD0.4040007@hp.com> Message-ID: <200510180848.23741.sgrubb@redhat.com> On Tuesday 18 October 2005 01:44, Matt Anderson wrote: > I had left a copyright in a file that didn't need it, and somehow included a > bunch of the CUPS code from scheduler/conf.c in the patch as additions. Traditionally, you update the changelog to mention your contribution. Adding a copyright is generally not done unless you write the *whole* file. Some open source projects would be offended by seeing a patch that inserts a copyright to *their* work, I don't know if cups is one of those projects. I believe credit should be given for the contribution. I don't think inserting copyrights is the right thing to do. Thanks, -Steve From sgrubb at redhat.com Tue Oct 18 13:08:06 2005 From: sgrubb at redhat.com (Steve Grubb) Date: Tue, 18 Oct 2005 09:08:06 -0400 Subject: [redhat-lspp] Patch - CUPS local unix sockets In-Reply-To: <435431AA.2090506@hp.com> References: <435431AA.2090506@hp.com> Message-ID: <200510180908.06314.sgrubb@redhat.com> On Monday 17 October 2005 19:20, Matt Anderson wrote: > As with before, comments, suggestions, and questions are welcome. In cups/scheduler/conf.c +strlcpy(temp->address.sun_path, value, 108); I think it would be better to base the size off of the sun_path instead of 108. BTW, in all the places you have 108, wouldn't it be better to have UNIX_PATH_MAX? +temp->address.sun_family = AF_LOCAL; In other places, you use AF_UNIX. Shouldn't this be consistent? >Currently this patch, like the two earlier CUPS patches, is based on >compile time switches. I'm planning on converting them all into run >time options so that there won't be the need for a separate certified >CUPS binary. We can't put this patch into rawhide until you do this. It would impact too many people as is. Thanks, -Steve From jmorris at redhat.com Tue Oct 18 15:10:22 2005 From: jmorris at redhat.com (James Morris) Date: Tue, 18 Oct 2005 11:10:22 -0400 (EDT) Subject: [redhat-lspp] Patch - CUPS local unix sockets In-Reply-To: <200510180848.23741.sgrubb@redhat.com> References: <435431AA.2090506@hp.com> <43548BD0.4040007@hp.com> <200510180848.23741.sgrubb@redhat.com> Message-ID: On Tue, 18 Oct 2005, Steve Grubb wrote: > Traditionally, you update the changelog to mention your contribution. Adding a > copyright is generally not done unless you write the *whole* file. Some open > source projects would be offended by seeing a patch that inserts a copyright > to *their* work, I don't know if cups is one of those projects. Well, it's common to add copyrights in the kernel if you modify a file. It's helpful for tracking ownership when someone comes along and asks to turn the code into LGPL, or when the code is copied somewhere else. - James -- James Morris From mra at hp.com Tue Oct 18 15:43:15 2005 From: mra at hp.com (Matt Anderson) Date: Tue, 18 Oct 2005 11:43:15 -0400 Subject: [redhat-lspp] Patch - CUPS local unix sockets In-Reply-To: <200510180848.23741.sgrubb@redhat.com> References: <435431AA.2090506@hp.com> <43548BD0.4040007@hp.com> <200510180848.23741.sgrubb@redhat.com> Message-ID: <43551813.4040904@hp.com> Steve Grubb wrote: > Traditionally, you update the changelog to mention your contribution. Adding a > copyright is generally not done unless you write the *whole* file. Some open > source projects would be offended by seeing a patch that inserts a copyright > to *their* work, I don't know if cups is one of those projects. > > I believe credit should be given for the contribution. I don't think inserting > copyrights is the right thing to do. I was simply following TCS's lead in adding the copyright notice to the files I modified with the patch. I'll double-check HP's policy when it comes to licensing changes to open source projects, but I believe I was doing the right thing. -matt From sgrubb at redhat.com Tue Oct 18 15:50:02 2005 From: sgrubb at redhat.com (Steve Grubb) Date: Tue, 18 Oct 2005 11:50:02 -0400 Subject: [redhat-lspp] Patch - CUPS local unix sockets In-Reply-To: <43551813.4040904@hp.com> References: <435431AA.2090506@hp.com> <200510180848.23741.sgrubb@redhat.com> <43551813.4040904@hp.com> Message-ID: <200510181150.02276.sgrubb@redhat.com> On Tuesday 18 October 2005 11:43, Matt Anderson wrote: > I was simply following TCS's lead in adding the copyright notice to the > files I modified with the patch. OK. I guess leave it. -Steve From mra at hp.com Tue Oct 18 15:52:03 2005 From: mra at hp.com (Matt Anderson) Date: Tue, 18 Oct 2005 11:52:03 -0400 Subject: [redhat-lspp] Patch - CUPS local unix sockets In-Reply-To: <200510180908.06314.sgrubb@redhat.com> References: <435431AA.2090506@hp.com> <200510180908.06314.sgrubb@redhat.com> Message-ID: <43551A23.5050504@hp.com> Steve Grubb wrote: > In cups/scheduler/conf.c > > +strlcpy(temp->address.sun_path, value, 108); > > I think it would be better to base the size off of the sun_path instead of > 108. BTW, in all the places you have 108, wouldn't it be better to have > UNIX_PATH_MAX? This was something that bothered me when I was writing it. only has 108 in the sockaddr_un data structure and I thought a #defined constant would be better. Now that you mention UNIX_PATH_MAX I see there is a which has that #define and essentially the same data structure. I'll add some logic to the runtime version to use that if available. > +temp->address.sun_family = AF_LOCAL; > > In other places, you use AF_UNIX. Shouldn't this be consistent? Yes, good catch, thanks. -matt From sgrubb at redhat.com Tue Oct 18 16:00:53 2005 From: sgrubb at redhat.com (Steve Grubb) Date: Tue, 18 Oct 2005 12:00:53 -0400 Subject: [redhat-lspp] Patch - CUPS local unix sockets In-Reply-To: <43551A23.5050504@hp.com> References: <435431AA.2090506@hp.com> <200510180908.06314.sgrubb@redhat.com> <43551A23.5050504@hp.com> Message-ID: <200510181200.53232.sgrubb@redhat.com> On Tuesday 18 October 2005 11:52, Matt Anderson wrote: > Now that you mention UNIX_PATH_MAX I see there is a which has > that #define and essentially the same data structure. ?I'll add some logic > to the runtime version to use that if available. I'd just do strlcpy(temp->address.sun_path, value, sizeof(temp->address.sun_path)); and not worry. -Steve From mrmacman_g4 at mac.com Tue Oct 18 19:47:10 2005 From: mrmacman_g4 at mac.com (Kyle Moffett) Date: Tue, 18 Oct 2005 15:47:10 -0400 Subject: [redhat-lspp] Re: [Keyrings] [RFC] Coming key management support improvements In-Reply-To: <25248.1129638077@warthog.cambridge.redhat.com> References: <3014.1129553636@warthog.cambridge.redhat.com> <5378.1127211442@warthog.cambridge.redhat.com> <25248.1129638077@warthog.cambridge.redhat.com> Message-ID: <1BC48FF8-0FDB-4662-8A29-C88A022DEEB2@mac.com> On Oct 18, 2005, at 08:21:17, David Howells wrote: > Hi Trond, >>> (3) Make it possible for request_key() to avoid forking and >>> executing /sbin/request-key when a new key needs to be >>> instantiated, but instead talk to some already running process to >>> do the honours. > > Can you remind me just why this is necessary? It seems like the obvious answer is to avoid massive fork()/exec() load placed on a system handling lots of keys, similar to the idea that high-load servers don't run Apache from inetd. Cheers, Kyle Moffett -- Q: Why do programmers confuse Halloween and Christmas? A: Because OCT 31 == DEC 25. From dhowells at redhat.com Tue Oct 18 20:10:27 2005 From: dhowells at redhat.com (David Howells) Date: Tue, 18 Oct 2005 21:10:27 +0100 Subject: [redhat-lspp] Re: [Keyrings] [RFC] Coming key management support improvements In-Reply-To: <1BC48FF8-0FDB-4662-8A29-C88A022DEEB2@mac.com> References: <1BC48FF8-0FDB-4662-8A29-C88A022DEEB2@mac.com> <3014.1129553636@warthog.cambridge.redhat.com> <5378.1127211442@warthog.cambridge.redhat.com> <25248.1129638077@warthog.cambridge.redhat.com> Message-ID: <14815.1129666227@warthog.cambridge.redhat.com> Kyle Moffett wrote: > It seems like the obvious answer is to avoid massive fork()/exec() load > placed on a system handling lots of keys, similar to the idea that high-load > servers don't run Apache from inetd. Yes, but why should there be more than one key per mountpoint? I wouldn't have thought that'd be an excessive load. David From chrisw at osdl.org Tue Oct 18 21:10:16 2005 From: chrisw at osdl.org (Chris Wright) Date: Tue, 18 Oct 2005 14:10:16 -0700 Subject: [redhat-lspp] Re: [Keyrings] [RFC] Coming key management support improvements In-Reply-To: <14815.1129666227@warthog.cambridge.redhat.com> References: <1BC48FF8-0FDB-4662-8A29-C88A022DEEB2@mac.com> <3014.1129553636@warthog.cambridge.redhat.com> <5378.1127211442@warthog.cambridge.redhat.com> <25248.1129638077@warthog.cambridge.redhat.com> <14815.1129666227@warthog.cambridge.redhat.com> Message-ID: <20051018211016.GO5856@shell0.pdx.osdl.net> * David Howells (dhowells at redhat.com) wrote: > Yes, but why should there be more than one key per mountpoint? I wouldn't have > thought that'd be an excessive load. I'm with you. Hard to imagine this as load intensive. thanks, -chris From ltcgcw at us.ibm.com Tue Oct 18 22:35:50 2005 From: ltcgcw at us.ibm.com (George Wilson) Date: Tue, 18 Oct 2005 17:35:50 -0500 Subject: [redhat-lspp] [Reminder] Open LSPP Development Telecon Message-ID: <1129674950.21689.35.camel@ea.austin.ibm.com> IBM hosts a telecon every Wednesday morning to discuss the development issues surrounding Linux LSPP certification. The call is open to all who have something to bring to the effort. If you would like to participate and are not already an attendee, please reply directly to me with your contact information. I will respond with an invitation. Please note that the number of attendees may be limited by our call center's restrictions on maximum lines per conference. -- George Wilson IBM Linux Technology Center From kwc at citi.umich.edu Tue Oct 18 21:36:44 2005 From: kwc at citi.umich.edu (Kevin Coffman) Date: Tue, 18 Oct 2005 17:36:44 -0400 Subject: [redhat-lspp] Re: [Keyrings] [RFC] Coming key management support improvements In-Reply-To: <14815.1129666227@warthog.cambridge.redhat.com> References: <1BC48FF8-0FDB-4662-8A29-C88A022DEEB2@mac.com> <3014.1129553636@warthog.cambridge.redhat.com> <5378.1127211442@warthog.cambridge.redhat.com> <25248.1129638077@warthog.cambridge.redhat.com> <14815.1129666227@warthog.cambridge.redhat.com> Message-ID: <20051018213644.42C521BB95@citi.umich.edu> > Kyle Moffett wrote: > > > It seems like the obvious answer is to avoid massive fork()/exec() > > load placed on a system handling lots of keys, similar to the idea > > that high-load servers don't run Apache from inetd. > > Yes, but why should there be more than one key per mountpoint? > I wouldn't have thought that'd be an excessive load. I won't try to answer for Trond's intent, but it would make it possible for us to use our existing gssd daemon. This is also one key per user per mountpoint, so there is potential for a load problem with all these forks. K.C. From trond.myklebust at fys.uio.no Tue Oct 18 21:37:22 2005 From: trond.myklebust at fys.uio.no (Trond Myklebust) Date: Tue, 18 Oct 2005 14:37:22 -0700 Subject: [redhat-lspp] Re: [Keyrings] [RFC] Coming key management support improvements In-Reply-To: <14815.1129666227@warthog.cambridge.redhat.com> References: <1BC48FF8-0FDB-4662-8A29-C88A022DEEB2@mac.com> <3014.1129553636@warthog.cambridge.redhat.com> <5378.1127211442@warthog.cambridge.redhat.com> <25248.1129638077@warthog.cambridge.redhat.com> <14815.1129666227@warthog.cambridge.redhat.com> Message-ID: <1129671443.9344.12.camel@lade.trondhjem.org> ty den 18.10.2005 klokka 21:10 (+0100) skreiv David Howells: > Kyle Moffett wrote: > > > It seems like the obvious answer is to avoid massive fork()/exec() load > > placed on a system handling lots of keys, similar to the idea that high-load > > servers don't run Apache from inetd. > > Yes, but why should there be more than one key per mountpoint? I wouldn't have > thought that'd be an excessive load. Sorry I'm a bit slow to respond this week: I'm out travelling again. Anyhow, fork()+exec can be a problem in the case of a server reboot. When the server comes up again _everybody_ that is using a file/directory/... on that server will want to re-establish their RPCSEC_GSS session. The result may then be a highly undesirable fork()+exec storm situation. Cheers, Trond From mrmacman_g4 at mac.com Tue Oct 18 23:24:14 2005 From: mrmacman_g4 at mac.com (Kyle Moffett) Date: Tue, 18 Oct 2005 19:24:14 -0400 Subject: [redhat-lspp] Re: [Keyrings] [RFC] Coming key management support improvements In-Reply-To: <14815.1129666227@warthog.cambridge.redhat.com> References: <1BC48FF8-0FDB-4662-8A29-C88A022DEEB2@mac.com> <3014.1129553636@warthog.cambridge.redhat.com> <5378.1127211442@warthog.cambridge.redhat.com> <25248.1129638077@warthog.cambridge.redhat.com> <14815.1129666227@warthog.cambridge.redhat.com> Message-ID: <09916CC0-9AC7-465A-B8B5-7635D1D5CC8A@mac.com> On Oct 18, 2005, at 16:10:27, David Howells wrote: > Kyle Moffett wrote: >> It seems like the obvious answer is to avoid massive fork()/exec >> () load placed on a system handling lots of keys, similar to the >> idea that high-load servers don't run Apache from inetd. > > Yes, but why should there be more than one key per mountpoint? I > wouldn't have thought that'd be an excessive load. Wasn't one of the plans to make Kerberos use the key system (instead of files) as a credentials cache? If so then a server using the Kerberos libraries to do user authentication might conceivably be doing a lot of key creations per second, without doing mounts or other stuff that might be more intensive. On systems where running a CGI is already too computationally intensive, that could theoretically be a showstopper. Cheers, Kyle Moffett -- Q: Why do programmers confuse Halloween and Christmas? A: Because OCT 31 == DEC 25. From paul.moore at hp.com Wed Oct 19 13:34:34 2005 From: paul.moore at hp.com (Paul Moore) Date: Wed, 19 Oct 2005 09:34:34 -0400 Subject: [redhat-lspp] [PATCH] Changes to dev_allocator-0.4 Message-ID: <43564B6A.1090500@hp.com> Attached is a patch with some changes to the updated dev_allocator sources Chad posted to the list last Friday (10/14). The ChangeLog entry is posted below. I didn't bother to update the RPM spec file as I saw that Dan Walsh posted a patch for that earlier this week and I wasn't sure if Chad/TCS had merged that patch yet. Regardless, there will be some minor changes needed to the spec file for this patch (look at the 'install' make targets). Comments and criticism are welcome. 2005-10-17 Paul Moore * Changed the class API to include an additional 'char *' for the purpose of passing options to the load/unload/reset functions. * Added the generic class. Right now all the generic class allows you to do is run a script when the load/unload/reset functions are executed. See /usr/share/devallocation/classes/{template,cups} for examples. * Added the noaction class which acts as a noop for the load/unload/reset functions. * Moved dev_allocation_setup from /etc/sysconfig/tcs to /sbin. * Moved dev_allocator.conf and supported_device_classes.conf from /etc/selinux to a policy specific directory. The library uses /etc/selinux/config to determine the current policy and looks there for the files, i.e. if you are running the MLS policy it looks in /etc/selinux/mls for the configuration files. * Added the optional LOAD_OPTS, UNLOAD_OPTS and RESET_OPTS fields to the dev_allocator.conf configuration file. * Created a more consistent naming convention. The library include file was renamed to match the libarary (devallocation.h) and the library API functions are now pre-fixed with 'devalloc_', i.e. init() is now devalloc_init(). * Renamed dev_internal.h to devallocation_internal.h. * Minor formatting changes to better fit on an 80 char wide terminal. * Added audit messages whenever a device changes context. Eventually we should probably give the library it's own audit message type and decide on a better message itself but this should suffice for now. * The functions set_allocated_context() and set_unallocated_context() now return the new context of the specified device to make auditing easier. * Added the devalloc_status() library call which returns the status, allocated or unallocated, and the context of the specified device. * Added the '-s ' option to dev_allocator to query the status of a device. * Added the devalloc_close() library call which disconnects from the audit subsystem and frees some internal memory. -- . paul moore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . paul.moore at hp.com hewlett packard . (603) 884-5056 linux security -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch-10192005.txt URL: From janak at us.ibm.com Thu Oct 20 15:00:39 2005 From: janak at us.ibm.com (Janak Desai) Date: Thu, 20 Oct 2005 11:00:39 -0400 (Eastern Daylight Time) Subject: [redhat-lspp] [PATCH 1/2] New system call unshare Message-ID: Hi all, I am still working with Chris Wright on investigating is clone() can be used in PAM, but in the meantime Steve Grubb suggested that it would be a good idea to start including unshare patches in the test kernel that is being built with audit patches. This patch incorporates feedback that was provided by Chris when it was posted on lkml about a week ago. The first patch implements the system call service routine and the second patch register the system call number for i386. -Janak ---------------------------------------------------------------- diff -Naurp 2.6.14-rc4-mm1/fs/namespace.c 2.6.14-rc4-mm1+unshare/fs/namespace.c --- 2.6.14-rc4-mm1/fs/namespace.c 2005-10-17 18:07:40.000000000 +0000 +++ 2.6.14-rc4-mm1+unshare/fs/namespace.c 2005-10-20 13:47:08.000000000 +0000 @@ -1069,9 +1069,7 @@ int copy_namespace(int flags, struct tas { struct namespace *namespace = tsk->namespace; struct namespace *new_ns; - struct vfsmount *rootmnt = NULL, *pwdmnt = NULL, *altrootmnt = NULL; - struct fs_struct *fs = tsk->fs; - struct vfsmount *p, *q; + int err = 0; if (!namespace) return 0; @@ -1082,10 +1080,35 @@ int copy_namespace(int flags, struct tas return 0; if (!capable(CAP_SYS_ADMIN)) { - put_namespace(namespace); - return -EPERM; + err = -EPERM; + goto out; + } + + new_ns = dup_namespace(tsk); + if (!new_ns) { + err = -ENOMEM; + goto out; } + tsk->namespace = new_ns; + +out: + put_namespace(namespace); + return err; +} + +/* + * Allocate a new namespace structure and populate it with contents + * copied from the namespace of the passed in task structure. + */ +struct namespace *dup_namespace(struct task_struct *tsk) +{ + struct namespace *namespace = tsk->namespace; + struct namespace *new_ns; + struct vfsmount *rootmnt = NULL, *pwdmnt = NULL, *altrootmnt = NULL; + struct fs_struct *fs = tsk->fs; + struct vfsmount *p, *q; + new_ns = kmalloc(sizeof(struct namespace), GFP_KERNEL); if (!new_ns) goto out; @@ -1134,8 +1157,6 @@ int copy_namespace(int flags, struct tas } up_write(&tsk->namespace->sem); - tsk->namespace = new_ns; - if (rootmnt) mntput(rootmnt); if (pwdmnt) @@ -1143,12 +1164,8 @@ int copy_namespace(int flags, struct tas if (altrootmnt) mntput(altrootmnt); - put_namespace(namespace); - return 0; - out: - put_namespace(namespace); - return -ENOMEM; + return new_ns; } asmlinkage long sys_mount(char __user * dev_name, char __user * dir_name, diff -Naurp 2.6.14-rc4-mm1/include/linux/namespace.h 2.6.14-rc4-mm1+unshare/include/linux/namespace.h --- 2.6.14-rc4-mm1/include/linux/namespace.h 2005-08-28 23:41:01.000000000 +0000 +++ 2.6.14-rc4-mm1+unshare/include/linux/namespace.h 2005-10-20 13:48:15.000000000 +0000 @@ -14,6 +14,7 @@ struct namespace { extern int copy_namespace(int, struct task_struct *); extern void __put_namespace(struct namespace *namespace); +extern struct namespace *dup_namespace(struct task_struct *); static inline void put_namespace(struct namespace *namespace) { diff -Naurp 2.6.14-rc4-mm1/kernel/fork.c 2.6.14-rc4-mm1+unshare/kernel/fork.c --- 2.6.14-rc4-mm1/kernel/fork.c 2005-10-17 18:09:00.000000000 +0000 +++ 2.6.14-rc4-mm1+unshare/kernel/fork.c 2005-10-20 12:40:06.000000000 +0000 @@ -446,6 +446,55 @@ void mm_release(struct task_struct *tsk, } } +/* + * Allocate a new mm structure and copy contents from the + * mm structure of the passed in task structure. + */ +static struct mm_struct *dup_mm(struct task_struct *tsk) +{ + struct mm_struct *mm, *oldmm = current->mm; + int err; + + if (!oldmm) + return NULL; + + mm = allocate_mm(); + if (!mm) + goto fail_nomem; + + memcpy(mm, oldmm, sizeof(*mm)); + + if (!mm_init(mm)) + goto fail_nomem; + + if (init_new_context(tsk, mm)) + goto fail_nocontext; + + err = dup_mmap(mm, oldmm); + if (err) + goto free_pt; + + mm->hiwater_rss = get_mm_rss(mm); + mm->hiwater_vm = mm->total_vm; + + return mm; + +free_pt: + mmput(mm); + +fail_nomem: + return NULL; + +fail_nocontext: + /* + * If init_new_context() failed, we cannot use mmput() to free the mm + * because it calls destroy_context() + */ + mm_free_pgd(mm); + free_mm(mm); + return NULL; +} + static int copy_mm(unsigned long clone_flags, struct task_struct * tsk) { struct mm_struct * mm, *oldmm; @@ -480,43 +529,17 @@ static int copy_mm(unsigned long clone_f } retval = -ENOMEM; - mm = allocate_mm(); + mm = dup_mm(tsk); if (!mm) goto fail_nomem; - /* Copy the current MM stuff.. */ - memcpy(mm, oldmm, sizeof(*mm)); - if (!mm_init(mm)) - goto fail_nomem; - - if (init_new_context(tsk,mm)) - goto fail_nocontext; - - retval = dup_mmap(mm, oldmm); - if (retval) - goto free_pt; - - mm->hiwater_rss = get_mm_rss(mm); - mm->hiwater_vm = mm->total_vm; - good_mm: tsk->mm = mm; tsk->active_mm = mm; return 0; -free_pt: - mmput(mm); fail_nomem: return retval; - -fail_nocontext: - /* - * If init_new_context() failed, we cannot use mmput() to free the mm - * because it calls destroy_context() - */ - mm_free_pgd(mm); - free_mm(mm); - return retval; } static inline struct fs_struct *__copy_fs_struct(struct fs_struct *old) @@ -1319,3 +1342,101 @@ void __init proc_caches_init(void) sizeof(struct mm_struct), 0, SLAB_HWCACHE_ALIGN|SLAB_PANIC, NULL, NULL); } + +/* + * Performs sanity checks on the flags passed to the unshare system + * call. + */ +static inline int check_unshare_flags(unsigned long unshare_flags) +{ + int err = -EINVAL; + + if (unshare_flags & ~(CLONE_NEWNS | CLONE_VM)) + goto errout; + + /* + * Cannot unshare namespace if the fs structure is being shared + * through a previous call to clone() + */ + if ((unshare_flags & CLONE_NEWNS) && + (atomic_read(¤t->fs->count) > 1)) + goto errout; + + /* + * Cannot unshare vm if sighnal handlers are being shared through + * a previous call to clone() + */ + if ((unshare_flags & CLONE_VM) && + (atomic_read(¤t->sighand->count) > 1)) + goto errout; + + return 0; + +errout: + return err; + +} + +/* + * unshare allows a process to 'unshare' part of the process + * context which was originally shared using clone. copy_* + * functions used by do_fork() cannot be used here directly + * because they modify an inactive task_struct that is being + * constructed. Here we are modifying the current, active, + * task_struct. + */ +asmlinkage long sys_unshare(unsigned long unshare_flags) +{ + int err = 0; + struct namespace *new_ns = NULL, *ns = current->namespace; + struct mm_struct *new_mm = NULL, *active_mm = NULL, *mm = current->mm; + + err = check_unshare_flags(unshare_flags); + if (err) + goto unshare_out; + + if ((unshare_flags & CLONE_NEWNS) && + (ns && atomic_read(&ns->count) > 1)) { + err = -EPERM; + if (!capable(CAP_SYS_ADMIN)) + goto unshare_out; + + err = -ENOMEM; + new_ns = dup_namespace(current); + if (!new_ns) + goto unshare_out; + } + + if ((unshare_flags & CLONE_VM) && (atomic_read(&mm->mm_users) > 1)) { + err = -ENOMEM; + new_mm = dup_mm(current); + if (!new_mm) + goto unshare_cleanup_ns; + } + + if (new_ns) { + task_lock(current); + current->namespace = new_ns; + task_unlock(current); + put_namespace(ns); + } + + if (new_mm) { + task_lock(current); + active_mm = current->active_mm; + current->mm = new_mm; + current->active_mm = new_mm; + activate_mm(active_mm, new_mm); + task_unlock(current); + mmput(mm); + } + + return 0; + +unshare_cleanup_ns: + if (new_ns) + put_namespace(new_ns); + +unshare_out: + return err; +} From janak at us.ibm.com Thu Oct 20 15:02:30 2005 From: janak at us.ibm.com (Janak Desai) Date: Thu, 20 Oct 2005 11:02:30 -0400 (Eastern Daylight Time) Subject: [redhat-lspp] [PATCH 2/2] New system call unshare Message-ID: Part II of the patch that registers the new system call for i386 architecture. --------------------------------------------------------------- diff -Naurp 2.6.14-rc4-mm1/arch/i386/kernel/syscall_table.S 2.6.14-rc4-mm1+unshare+build/arch/i386/kernel/syscall_table.S --- 2.6.14-rc4-mm1/arch/i386/kernel/syscall_table.S 2005-08-28 23:41:01.000000000 +0000 +++ 2.6.14-rc4-mm1+unshare+build/arch/i386/kernel/syscall_table.S 2005-10-17 18:23:11.000000000 +0000 @@ -294,3 +294,4 @@ ENTRY(sys_call_table) .long sys_inotify_init .long sys_inotify_add_watch .long sys_inotify_rm_watch + .long sys_unshare diff -Naurp 2.6.14-rc4-mm1/include/asm-i386/unistd.h 2.6.14-rc4-mm1+unshare+build/include/asm-i386/unistd.h --- 2.6.14-rc4-mm1/include/asm-i386/unistd.h 2005-10-17 18:08:58.000000000 +0000 +++ 2.6.14-rc4-mm1+unshare+build/include/asm-i386/unistd.h 2005-10-17 18:22:08.000000000 +0000 @@ -299,8 +299,9 @@ #define __NR_inotify_init 291 #define __NR_inotify_add_watch 292 #define __NR_inotify_rm_watch 293 +#define __NR_unshare 294 -#define NR_syscalls 294 +#define NR_syscalls 295 /* * user-visible error numbers are in the range -1 - -128: see From dwalsh at redhat.com Thu Oct 20 15:25:27 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 20 Oct 2005 11:25:27 -0400 Subject: [redhat-lspp] Fedora on P Series should be working Message-ID: <4357B6E7.7070406@redhat.com> Talked to Paul Nasrat and he states that most P-Series platforms should be working with today's Rawhide. He has some fixes that will go in tonight to fix a couple of problems also. Dan -- From ltcgcw at us.ibm.com Thu Oct 20 15:48:54 2005 From: ltcgcw at us.ibm.com (George Wilson) Date: Thu, 20 Oct 2005 10:48:54 -0500 Subject: [redhat-lspp] Fedora on P Series should be working In-Reply-To: <4357B6E7.7070406@redhat.com> References: <4357B6E7.7070406@redhat.com> Message-ID: <1129823334.21689.87.camel@ea.austin.ibm.com> On Thu, 2005-10-20 at 11:25 -0400, Daniel J Walsh wrote: > Talked to Paul Nasrat and he states that most P-Series platforms should > be working with today's Rawhide. He has some fixes that will go in > tonight to fix a couple of problems also. > > Dan > Thanks much, Dan. I'll give it a whirl. -- George Wilson IBM Linux Technology Center From dvelarde at us.ibm.com Mon Oct 24 20:27:20 2005 From: dvelarde at us.ibm.com (Debora Velarde) Date: Mon, 24 Oct 2005 15:27:20 -0500 Subject: [redhat-lspp] LSPP Development Telecon 10/19/2005 Minutes Message-ID: Following are minutes from the 10/19/2005 LSPP teleconference with a few minor edits by George Wilson. ------------------------ LSPP Meeting 10/19/2005 ------------------------ Known Attendees: Matt Anderson (HP) Tim Chavez (IBM) Janak Desai (IBM) Amy Griffins (HP) Steve Grubb (Red Hat) Ken Hake (IBM) Chad Hanson (TCS) Trent Jaeger (PSU) Dustin Kirkland (IBM) Linda Knippers (HP) Paul Moore (HP) Emily Ratliff (IBM) Debora Velarde (IBM) Dan Walsh (Red Hat) Klaus Weidner (atsec) George Wilson (IBM) Kris Wilson (IBM) Catherine Zhang (IBM) Tentative Agenda: Tasks and assignments IPsec labels VFS polyinstantiation Device allocation Audit Documentation Test --------------------- Tasks and assignments --------------------- - George and Steve have exchanged lists of work items. - Discussed with Klaus. - George has list in mySQL DB; when done willing to share DB. - Could have Russell host it on a wiki. That way people could update their own items. ------------ IPsec labels ------------ - Updates to patch. - Submitted revision of patch on Friday. - Trent's requirements different than Herbert's. Revising patch to meet semantics Herbert wanted. Simplifies code in useful ways. - Server socket being able to receive sockets from different labelled sockets on the same flow. Prototyped it. - Need to get correct behavior of flow cache solved first. - If at user-level you want to know who your connected to, who your peers are, then needs more work. Trent hoping Catherine can help with design of that. - ACTION: George to split line item into 3 or 4 diff line items. Once these issues are addressed, will it be appropriate for this to go forward? Trent: Herbert indicated that this should be upstreamable pretty soon, thinks this is the remaining issue. Joy will probably submit the ipsec-tools patch to accompany it. Catherine and Joy have task of putting a usage doc to the redhat-lspp. ------- Unshare ------- - Received feedback from Chris Wright and Jaime. - Incorporated and patched against mm tree. - Chris Wright wanted to know it wasn't possible to use clone. Janak and Steve explained why. Can't get it to work with PAM like they want it to. Chris Wright was going to try some things out. - Janak will resubmit to LKML once he gets OK from Chris Wright. - Steve gave good feedback about userspace. - If they can't accept unshare then need to move it to (login, ssh, etc.). Really ugly. Could break something for other non-LSPP users like CAPP users. Still hoping we can get unshare upstream. Then can do PAM namespace module. ----------------- Device allocation ----------------- - New device allocator RPM from TCS posted to redhat-lspp. - Thanks, Chad, for the license of the device allocator. - New patch to it from Paul posted to redhat-lspp. - Changes (see changelog in patch). New classes: Noaction class - load, unload, reset, returns zero and does nothing). Generic class - Allows you to spawn external program for load,unload,reset. - Initial reason was for CUPS. Similar concerns of namespace collisions on some of the class libraries. Changed name of the include file names. Minor formatting changes. Added auditing msgs. - Please look at patch, send feedback. ----- Print ----- - New print patch from Matt. - Beginning to make CUPS use a local socket. - Converting it to something that is runtime rather than compile time. - Planning to convert TCS's earlier patch to something that could be specified in a config file also. -------------- Test - pSeries -------------- - Still can't get rawhide installed on pSeries boxes. Affects test effort since many of IBM test systems are pSeries. Dustin: need to talk to Paul Nasrat (always on IRC). Dan Walsh can ask him to look at it. Paul will be on IBM site next week. ----------------------------------------- User Data Protection import/export pieces ----------------------------------------- D-BUS - D-BUS could be admin only. - Print could use it but normal users couldn't. - D-BUS has permissions on socket when it comes up. - It is an IPC mechanism. - Has policy, AVC messages. - Local host version of CORBA (complex piece to test). - If there's a way to restrict that would be good. - Would be good if could have it off. - Need to install a server, turn it off, and see what breaks. - Needs more analysis. ---- Mail ---- procmail - sufficient on its own? - Audit daemon using email notification. - Admin only knows if they are out of diskspace if they are at that machine. - Usability issue. - For cron jobs: that can go to the local machine. - Would it be sufficient to have an admin sendmail or postfix daemon that would be restricted to admin? - Is there a daemon running at this label to send out? - Needs to be a policy patch. - Audit daemon needs to run at system high. - Is there going to be an email running at audit daemon level? - If audit is running at system high, doesn't the msg need to be at system high? - Audit daemon makes the msg, invokes sendmail command line. - Would have to be system high since that's what the daemon high. - Do we need email in evaluation? - Need to seriously look at this. Klaus suggestion: just use procmail for local delivery? Klaus: Do we even need procmail? Or just specialized delivery of the cron msgs (not saying its a good idea just an alternative to consider). Cron could directly place files in the correct multilevel home directories. Does TCS have a multi-level mail solution? Chad: Don't know that we have one offhand, but have in the past. If just trying to monitor stuff could have different things monitoring. Don't have a true multilevel mail solution. Is it still worth working on a solution after completing the items needed for evaluation? Interesting question. More investigation required. ------- Slocate ------- Russell has had fun with slocate with root and some restricted SELinux user. Hopefully we'll be OK with slocate. Klaus proposes getting rid of slocate and just keeping find command. Thinks slocate is a potential security hole. Could restrict this through policy. Folks on call agree don't want slocate in evaluation. Pull the package. ----- Audit ----- Steve's Status: - Haven't been doing a lot of audit. - Working on 1.0.7 gdm, secure shell, PAM, getting things ready for RHEL4U3. Amy's Status: - Finished testing she was doing. - Sent patch to Tim (haven't been able to get in touch with him for 1 1/2 days). - ACTION: Amy to go ahead and post patch to the list. - Tim sent Amy a patch. She'll try to get a hold with him later with her comments? She would prefer to talk to Tim about it first. Tim's Status: - Had problem getting an SMP system setup. - Hasn't had a chance to look at Amy's patch. Dustin's Status: - Put out a new version last night addressing Chris Wright's concerns. - Expecting one more iteration today (Amy's comments). - The way he is about to submit this newest patch, take us back to the issue we haven't had agreement on yet: When an audit record is being generated that is for an object, in LSPP we have subjects acting on objects. Example, IPC call or move or copy. The filesystem record is the object. The context ties to that object. Looks cleaner but adds clutter to CAPP. Latest version: looks cleaner (var/log/audit.log) appending subject and object label. Steve Grubb uneasy because clutters the audit record for non-LSPP environments (disk space). Needs to work with the old fs auditing system. Wants to wait until fs auditing piece to make a decision. -------- SELinux -------- Dan: - Biggest change: seusers capability - can login as a range of sensitivity labels. With MCS can play with users having different levels. - On-going work on reference policy. Dan's opinion not ready to go prime time. Building RPMs on a daily basis. George: are you going to work to the reference policy for RHEL5? Dan: Want to but can't get it to build. Need to get reference policy for 3rd party usage. - MCS stuff is in reference policy. Chris PeBenito has been taking Dan's changes and putting them into reference policy. - Managing the users in flat files -> seusers. Is that completely done with hand editing. Would like it in LDAP. If we add library where should it be in? Can't allow users to hand edit it for evaluation. Need to build an editing tool instead of a library. Could build equivalent of adduser, that can add and remove entries, need to audit changes to that file. Also need to audit roles. Dan will put together in python (about a day's effort). - newrole needs to be a trusted program (suid); will drop all capabilities except CAP_AUDIT_WRITE. - chcon Don't think we need to do anything to it Syscall audit for anything on extended attributes should be covered. - Need code review; there is some nastiness that needs some patching up. - George can take a look at some of these userspace items. Coverity Look at it with a broader role of what changes need to be run on it. - Multi-level xinitd Do we need multi-level tmpwatch? or can we drop that from the list? A tmpwatch that may need to be multi-level aware. Probably needs to be polyinstantiated aware. Janak will take a look at it. - Audit of service discontinuity. Special recovery mode. Do we need an additional runlevel. Does this need to be distinct from single user mode? Klaus thinks single user mode should meet these requirements. - Rework sys init - calls fixfiles restore. Don't want it to automatically call fixfiles. This is more of an RBAC not MLS thing. Could require changes to the boot process (not big but need to be careful not to break other things). whether it should default to automatically repair. Do we need an approval from the admin or does he need to go to a shell? Might want to gather forensic evidence. Option of auto fix or user shell. Dan: This should be assigned to me. From dvelarde at us.ibm.com Mon Oct 24 22:14:18 2005 From: dvelarde at us.ibm.com (Debora Velarde) Date: Mon, 24 Oct 2005 16:14:18 -0600 Subject: [redhat-lspp] zip unzip - restore xattr patches Message-ID: Below are patches to zip and unzip that will allow administrators to restore extended attributes. I understand star already does this, but this gives administrators another option. Usage: zip Will store extended attributes in the archive file by default unless the existing option: "-X eXclude eXtra file attributes" is used. unzip Will NOT restore extended attributes by default. Will only restore extended attributes if used with the new option: "-E restore extended attributes". The new -E option can only be used in conjunction with the existing: "-X restore UID/GID info" option. Users can still choose to restore only the UID/GID info with the existing '-X' option. Please send me any feedback. Thanks, debora diff -urpN zip-2.3.orig/unix/Makefile zip-2.3/unix/Makefile --- zip-2.3.orig/unix/Makefile 2005-10-10 13:55:45.000000000 -0500 +++ zip-2.3/unix/Makefile 2005-10-24 15:38:44.000000000 -0500 @@ -59,7 +59,7 @@ OBJN = zipnote.o $(OBJU) OBJC = zipcloak.o $(OBJU) crctab.o crypt_.o ttyio.o OBJS = zipsplit.o $(OBJU) -ZIP_H = zip.h ziperr.h tailor.h unix/osdep.h +ZIP_H = zip.h ziperr.h tailor.h unix/osdep.h unix/xattr.h # suffix rules .SUFFIXES: diff -urpN zip-2.3.orig/unix/unix.c zip-2.3/unix/unix.c --- zip-2.3.orig/unix/unix.c 2005-10-10 13:55:45.000000000 -0500 +++ zip-2.3/unix/unix.c 2005-10-24 15:38:44.000000000 -0500 @@ -11,6 +11,7 @@ #ifndef UTIL /* the companion #endif is a bit of ways down ... */ #include +#include "xattr.h" #if defined(MINIX) || defined(__mpexl) # ifdef S_IWRITE @@ -40,6 +41,8 @@ # endif #endif /* HAVE_DIRENT_H || _POSIX_VERSION */ +#include + #define PAD 0 #define PATH_END '/' @@ -436,19 +439,80 @@ int set_extra_field(z, z_utim) struct stat s; #endif +char * xa_list; +char * xa_name; +char * xa_value; +ssize_t xa_list_len=0; +ssize_t xa_name_len=0; +ssize_t xa_value_len=0; +int value_len=0; +int largest_value_len=0; +int ext_index=0; +int xa_pairs_found=0; +int value_index=1; +int i=0, j=0; + /* For the full sized UT local field including the UID/GID fields, we * have to stat the file again. */ if (LSSTAT(z->name, &s)) return ZE_OPEN; + #define EB_L_UT_SIZE (EB_HEADSIZE + EB_UT_LEN(2)) #define EB_C_UT_SIZE (EB_HEADSIZE + EB_UT_LEN(1)) #define EB_L_UX2_SIZE (EB_HEADSIZE + EB_UX2_MINLEN) #define EB_C_UX2_SIZE EB_HEADSIZE -#define EF_L_UNIX_SIZE (EB_L_UT_SIZE + EB_L_UX2_SIZE) -#define EF_C_UNIX_SIZE (EB_C_UT_SIZE + EB_C_UX2_SIZE) +#define EB_L_XA_SIZE (EB_HEADSIZE + EB_XA_MINLEN) +#define EB_C_XA_SIZE EB_HEADSIZE - if ((z->extra = (char *)malloc(EF_L_UNIX_SIZE)) == NULL) + /* Get size of xattr name list */ + /* Calling listxattr with NULL and zero returns the size */ + xa_list_len = listxattr(z->name, NULL, 0); + + if (xa_list_len > 0) { + + /* now that we know the size, alloc space for list */ + if ((xa_list = malloc(xa_list_len+1)) == NULL) + return ZE_MEM; + + /* Get the list of xattr names */ + xa_list_len = listxattr(z->name, xa_list, xa_list_len); + if (xa_list_len < 0) + return ZE_XATTR; + xa_name = xa_list; + xa_name_len = xa_list_len; + + /* figure out how many xattr names there are in the list */ + xa_pairs_found=get_xattr_count(xa_list, xa_list_len); + if (xa_pairs_found < 1) + return ZE_XATTR; + + /* Need to figure out the largest value_len before calling malloc */ + /* also need the sum of all value_lens; store it in xa_value_len */ + for (value_index=1; value_index <= xa_pairs_found; value_index++) { + xa_name=get_xattr_name(xa_list, xa_list_len, value_index); + if (xa_name == (char *)NULL) + return ZE_XATTR; + value_len=getxattr(z->name, xa_name, xa_value, 0); + if (value_len < 0) + return ZE_XATTR; + if (value_len > largest_value_len) + largest_value_len = value_len; + xa_value_len=xa_value_len + value_len + 1; + } + if ((xa_value = malloc(largest_value_len+1)) == NULL) + return ZE_MEM; + } + +#define EB_L_XN_SIZE (EB_HEADSIZE + EB_XA_MINLEN + xa_name_len) +#define EB_C_XN_SIZE EB_HEADSIZE +#define EB_L_XV_SIZE (EB_HEADSIZE + EB_XA_MINLEN + xa_value_len) +#define EB_C_XV_SIZE EB_HEADSIZE +#define EF_L_UNIX_SIZE (EB_L_UT_SIZE + EB_L_UX2_SIZE + EB_L_XA_SIZE + EB_L_XN_SIZE + EB_L_XV_SIZE) +#define EF_C_UNIX_SIZE (EB_C_UT_SIZE + EB_C_UX2_SIZE + EB_C_XA_SIZE + EB_C_XN_SIZE + EB_C_XV_SIZE) + + z->ext = EF_L_UNIX_SIZE; + if ((z->extra = (char *)malloc(z->ext)) == NULL) return ZE_MEM; if ((z->cextra = (char *)malloc(EF_C_UNIX_SIZE)) == NULL) return ZE_MEM; @@ -474,7 +538,71 @@ int set_extra_field(z, z_utim) z->extra[18] = (char)(s.st_uid >> 8); z->extra[19] = (char)(s.st_gid); z->extra[20] = (char)(s.st_gid >> 8); - z->ext = EF_L_UNIX_SIZE; + z->extra[21] = 'X'; + z->extra[22] = 'A'; + z->extra[23] = (char) xa_pairs_found; /* Number of xattr attributes*/ + z->extra[24] = 0; + z->extra[25] = 'X'; + z->extra[26] = 'N'; + z->extra[27] = (char) xa_name_len; /* length of xattr name list*/ + z->extra[28] = 0; + + ext_index=29; + + if (xa_list_len > 0) { + +/* Put all the xattr names in extra field */ + for (i=1; i<=xa_pairs_found; i++) { + xa_name=get_xattr_name(xa_list, xa_list_len, i); + if (xa_name == (char *)NULL) + return ZE_XATTR; + xa_name_len=strlen(xa_name); + if (xa_name_len < 1) + return ZE_XATTR; + for (j=0; jextra[ext_index+j]=(char) xa_name[j]; + } + ext_index = ext_index+j; + z->extra[ext_index] = '\0'; + ext_index++; + } + + z->extra[ext_index] = 'X'; + ext_index++; + z->extra[ext_index] = 'V'; + ext_index++; + z->extra[ext_index] = (char) xa_value_len; /* length of xattr value list*/ + ext_index++; + z->extra[ext_index] = 0; + ext_index++; + +/* Put all the xattr values in extra field */ + for (value_index=1; value_index <= xa_pairs_found; value_index++) { + xa_name=get_xattr_name(xa_list, xa_list_len, value_index); + if (xa_name == (char *)NULL) + return ZE_XATTR; + value_len=getxattr(z->name, xa_name, xa_value, 0); + if (value_len < 1) + return ZE_XATTR; + xa_value=memset(xa_value, 0, largest_value_len+1); + if (xa_value == (char *) NULL) + return ZE_MEM; + value_len=getxattr(z->name, xa_name, xa_value, value_len); + if (value_len < 1) + return ZE_XATTR; + + for (j=0; jextra[ext_index+j]=(char) xa_value[j]; + } + ext_index = ext_index+j; + z->extra[ext_index] = '\0'; + ext_index++; + } + + } /* if xa_list_len > 0 */ + + free(xa_list); + free(xa_value); memcpy(z->cextra, z->extra, EB_C_UT_SIZE); z->cextra[EB_LEN] = (char)EB_UT_LEN(1); diff -urpN zip-2.3.orig/unix/xattr.h zip-2.3/unix/xattr.h --- zip-2.3.orig/unix/xattr.h 1969-12-31 18:00:00.000000000 -0600 +++ zip-2.3/unix/xattr.h 2005-10-24 15:42:43.000000000 -0500 @@ -0,0 +1,67 @@ +/* + Copyright (C) 2005 IBM Corporation + Copyright (c) 1990-1999 Info-ZIP. All rights reserved. + + See the accompanying file LICENSE, version 1999-Oct-05 or later + (the contents of which are also included in zip.h) for terms of use. + If, for some reason, both of these files are missing, the Info-ZIP license + also may be found at: ftp://ftp.cdrom.com/pub/infozip/license.html +*/ + + +int get_xattr_count(char * xa_list, int xa_list_size) +{ +/* xattr names have the form name1.name2 */ +/* A file can have any number of xattr name pairs */ +/* This function returns the number of name pairs found */ +/* If list passed in is NULL or list size is less than 1 + function returns 0 */ + + int i=0; + int p=0; + + if ( (xa_list == (char *) NULL) || (xa_list_size < 1)) + return 0; + + while (i < xa_list_size) { + if ( xa_list[i] != '\0') { + i++; + } else { + i++; + p++; + } + } + return p; +} + +char * get_xattr_name(char * xa_list, int xa_list_size, int pair) +{ +/* xattr names have the form name1.name2 */ +/* A file can have any number of xattr name pairs */ +/* This function returns a pointer to the specified name pair */ +/* If list is NULL or size or pair are less than 1, then + function returns NULL */ + + int i=0; + int p=1; + char * tmp; + + tmp=NULL; + + if ( (xa_list == (char *) NULL) || (xa_list_size < 1) || (pair < 1) ) + return NULL; + + while ( (i < xa_list_size) && ( p != pair) ) { + if ( xa_list[i] != '\0') { + i++; + } else { + i++; + p++; + } + } + + if ( (p==pair) && (i < xa_list_size) ) + tmp=&xa_list[i]; + + return tmp; +} diff -urpN zip-2.3.orig/zip.c zip-2.3/zip.c --- zip-2.3.orig/zip.c 2005-10-10 14:11:49.000000000 -0500 +++ zip-2.3/zip.c 2005-10-24 15:38:44.000000000 -0500 @@ -980,7 +980,7 @@ char **argv; /* command line zp_tz_is_valid = VALID_TIMEZONE(p); #if (defined(AMIGA) || defined(DOS)) if (!zp_tz_is_valid) - extra_fields = 0; /* disable storing "UT" time stamps and xatter info*/ + extra_fields = 0; /* disable storing "UT" time stamps */ #endif /* AMIGA || DOS */ #endif /* IZ_CHECK_TZ && USE_EF_UT_TIME */ diff -urpN zip-2.3.orig/ziperr.h zip-2.3/ziperr.h --- zip-2.3.orig/ziperr.h 2005-10-10 13:55:45.000000000 -0500 +++ zip-2.3/ziperr.h 2005-10-24 15:38:44.000000000 -0500 @@ -31,8 +31,9 @@ #define ZE_CREAT 15 /* couldn't open to write */ #define ZE_PARMS 16 /* bad command line */ #define ZE_OPEN 18 /* could not open a specified file to read */ +#define ZE_XATTR 19 /* xattr error occurred */ -#define ZE_MAXERR 18 /* the highest error number */ +#define ZE_MAXERR 19 /* the highest error number */ /* Macro to determine whether to call perror() or not */ #define PERR(e) (e==ZE_READ||e==ZE_WRITE||e==ZE_CREAT||e==ZE_TEMP||e==ZE_OPEN) @@ -58,6 +59,7 @@ char *errors[ZE_MAXERR] = { /* 16 */ "Invalid command arguments", /* 17 */ "", /* 18 */ "File not found or no read permission" +/* 19 */ "Extended attributes failure" # ifdef AZTEC_C , /* extremely lame compiler bug workaround */ # endif diff -urpN zip-2.3.orig/zip.h zip-2.3/zip.h --- zip-2.3.orig/zip.h 2005-10-10 13:55:45.000000000 -0500 +++ zip-2.3/zip.h 2005-10-24 15:38:44.000000000 -0500 @@ -171,6 +171,9 @@ struct plist { #define EF_SPARK 0x4341 /* David Pilling's Acorn/SparkFS ("AC") */ #define EF_THEOS 0x6854 /* THEOS ("Th") */ #define EF_TANDEM 0x4154 /* Tandem NSK ("TA") */ +#define EF_XATTR 0x4158 /* XATTR ("XA") */ +#define EF_XA_NAME 0x4e58 /* XATTR NAME ("XN") */ +#define EF_XA_VALUE 0x5658 /* XATTR VALUE ("XV") */ /* Definitions for extra field handling: */ #define EF_SIZE_MAX ((unsigned)0xFFFF) /* hard limit of total e.f. length */ @@ -199,6 +202,8 @@ struct plist { #define EB_UX2_GID 2 /* byte offset of GID in "Ux" field data */ #define EB_UX2_VALID (1 << 8) /* UID/GID present */ +#define EB_XA_MINLEN 4 /* minimal XA field contains count */ + /* ASCII definitions for line terminators in text files: */ #define LF 10 /* '\n' on ASCII machines; must be 10 due to EBCDIC */ #define CR 13 /* '\r' on ASCII machines; must be 13 due to EBCDIC */ diff -urpN zip-2.3.orig/zip.h.4gb zip-2.3/zip.h.4gb --- zip-2.3.orig/zip.h.4gb 2005-10-10 13:55:45.000000000 -0500 +++ zip-2.3/zip.h.4gb 2005-10-24 15:38:44.000000000 -0500 @@ -171,6 +171,9 @@ struct plist { #define EF_SPARK 0x4341 /* David Pilling's Acorn/SparkFS ("AC") */ #define EF_THEOS 0x6854 /* THEOS ("Th") */ #define EF_TANDEM 0x4154 /* Tandem NSK ("TA") */ +#define EF_XATTR 0x4158 /* XATTR ("XA") */ +#define EF_XA_NAME 0x4e58 /* XATTR NAME ("XN") */ +#define EF_XA_VALUE 0x5658 /* XATTR VALUE ("XV") */ /* Definitions for extra field handling: */ #define EF_SIZE_MAX ((unsigned)0xFFFF) /* hard limit of total e.f. length */ @@ -199,6 +202,8 @@ struct plist { #define EB_UX2_GID 2 /* byte offset of GID in "Ux" field data */ #define EB_UX2_VALID (1 << 8) /* UID/GID present */ +#define EB_XA_MINLEN 4 /* minimal XA field contains count */ + /* ASCII definitions for line terminators in text files: */ #define LF 10 /* '\n' on ASCII machines; must be 10 due to EBCDIC */ #define CR 13 /* '\r' on ASCII machines; must be 13 due to EBCDIC */ diff -urpN zip-2.3.orig/zip.h.zip zip-2.3/zip.h.zip --- zip-2.3.orig/zip.h.zip 2005-10-10 13:55:45.000000000 -0500 +++ zip-2.3/zip.h.zip 2005-10-24 15:38:44.000000000 -0500 @@ -170,6 +170,10 @@ struct plist { #define EF_SPARK 0x4341 /* David Pilling's Acorn/SparkFS ("AC") */ #define EF_THEOS 0x6854 /* THEOS ("Th") */ #define EF_TANDEM 0x4154 /* Tandem NSK ("TA") */ +#define EF_XATTR 0x4158 /* XATTR ("XA") */ +#define EF_XA_NAME 0x4e58 /* XATTR NAME ("XN") */ +#define EF_XA_VALUE 0x5658 /* XATTR VALUE ("XV") */ + /* Definitions for extra field handling: */ #define EF_SIZE_MAX ((unsigned)0xFFFF) /* hard limit of total e.f. length */ @@ -198,6 +202,8 @@ struct plist { #define EB_UX2_GID 2 /* byte offset of GID in "Ux" field data */ #define EB_UX2_VALID (1 << 8) /* UID/GID present */ +#define EB_XA_MINLEN 4 /* minimal XA field contains count */ + /* ASCII definitions for line terminators in text files: */ #define LF 10 /* '\n' on ASCII machines; must be 10 due to EBCDIC */ #define CR 13 /* '\r' on ASCII machines; must be 13 due to EBCDIC */ diff -urpN unzip-5.51.orig/extract.c unzip-5.51/extract.c --- unzip-5.51.orig/extract.c 2005-09-08 14:25:57.000000000 -0500 +++ unzip-5.51/extract.c 2005-10-24 16:09:09.000000000 -0500 @@ -1908,6 +1908,9 @@ static int TestExtraField(__G__ ef, ef_l case EF_ASIUNIX: case EF_IZVMS: case EF_IZUNIX: + case EF_XATTR: + case EF_XA_NAME: + case EF_XA_VALUE: case EF_VMCMS: case EF_MVS: case EF_SPARK: diff -urpN unzip-5.51.orig/fileio.c unzip-5.51/fileio.c --- unzip-5.51.orig/fileio.c 2005-09-08 14:25:57.000000000 -0500 +++ unzip-5.51/fileio.c 2005-10-24 16:09:09.000000000 -0500 @@ -1833,6 +1833,9 @@ int check_for_newer(__G__ filename) /* #ifdef USE_EF_UT_TIME iztimes z_utime; #endif +#ifdef USE_EF_XATTR + izxattr z_xattr; +#endif #ifdef AOS_VS long dyy, dmm, ddd, dhh, dmin, dss; @@ -1902,7 +1905,11 @@ int check_for_newer(__G__ filename) /* G.tz_is_valid && #endif (ef_scan_for_izux(G.extra_field, G.lrec.extra_field_length, 0, +#ifdef USE_EF_XATTR + G.lrec.last_mod_dos_datetime, &z_utime, NULL, &z_xattr) +#else G.lrec.last_mod_dos_datetime, &z_utime, NULL) +#endif & EB_UT_FL_MTIME)) { TTrace((stderr, "check_for_newer: using Unix extra field mtime\n")); diff -urpN unzip-5.51.orig/list.c unzip-5.51/list.c --- unzip-5.51.orig/list.c 2005-09-08 14:25:57.000000000 -0500 +++ unzip-5.51/list.c 2005-10-24 16:09:09.000000000 -0500 @@ -104,6 +104,9 @@ int list_files(__G) /* return PK-type iztimes z_utime; struct tm *t; #endif +#ifdef USE_EF_XATTR + izxattr z_xattr; +#endif unsigned yr, mo, dy, hh, mm; ulg csiz; unsigned long long tot_csize=0, tot_ucsize=0; @@ -268,7 +271,12 @@ int list_files(__G) /* return PK-type G.tz_is_valid && #endif (ef_scan_for_izux(G.extra_field, G.crec.extra_field_length, 1, - G.crec.last_mod_dos_datetime, &z_utime, NULL) + G.crec.last_mod_dos_datetime, &z_utime, +#ifdef USE_EF_XATTR + NULL, &z_xattr) +#else + NULL) +#endif & EB_UT_FL_MTIME)) { TIMET_TO_NATIVE(z_utime.mtime) /* NOP unless MSC 7.0, Mac */ @@ -509,6 +517,9 @@ int get_time_stamp(__G__ last_modtime, n #ifdef USE_EF_UT_TIME iztimes z_utime; #endif +#ifdef USE_EF_XATTR + iztimes z_xattr; +#endif min_info info; @@ -594,7 +605,12 @@ int get_time_stamp(__G__ last_modtime, n G.tz_is_valid && #endif (ef_scan_for_izux(G.extra_field, G.crec.extra_field_length, 1, - G.crec.last_mod_dos_datetime, &z_utime, NULL) + G.crec.last_mod_dos_datetime, &z_utime, +#ifdef USE_EF_XATTR + NULL, &z_xattr) +#else + NULL) +#endif & EB_UT_FL_MTIME)) { if (*last_modtime < z_utime.mtime) diff -urpN unzip-5.51.orig/Makefile unzip-5.51/Makefile --- unzip-5.51.orig/Makefile 2005-09-08 14:25:57.000000000 -0500 +++ unzip-5.51/Makefile 2005-10-24 16:09:09.000000000 -0500 @@ -81,14 +81,14 @@ CRC32 = crc32 OSDEP_H = # object files -OBJS1 = unzip$O $(CRC32)$O crctab$O crypt$O envargs$O explode$O +OBJS1 = unzip$O $(CRC32)$O crctab$O crypt$O envargs$O explode$O xattr$O OBJS2 = extract$O fileio$O globals$O inflate$O list$O match$O OBJS3 = process$O ttyio$O unreduce$O unshrink$O zipinfo$O OBJS = $(OBJS1) $(OBJS2) $(OBJS3) $M$O LOBJS = $(OBJS) OBJSDLL = $(OBJS:.o=.pic.o) api.pic.o OBJX = unzipsfx$O $(CRC32)$O crctab_$O crypt_$O extract_$O fileio_$O \ - globals_$O inflate_$O match_$O process_$O ttyio_$O $M_$O + globals_$O inflate_$O match_$O process_$O ttyio_$O xattr_$O $M_$O LOBJX = $(OBJX) OBJF = funzip$O $(CRC32)$O cryptf$O globalsf$O inflatef$O ttyiof$O #OBJS_OS2 = $(OBJS1:.o=.obj) $(OBJS2:.o=.obj) os2.obj @@ -300,6 +300,7 @@ ttyio$O: ttyio.c $(UNZIP_H) zip.h crypt. unreduce$O: unreduce.c $(UNZIP_H) unshrink$O: unshrink.c $(UNZIP_H) unzip$O: unzip.c $(UNZIP_H) crypt.h unzvers.h consts.h +xattr$O: xattr.c $(UNZIP_H) zipinfo$O: zipinfo.c $(UNZIP_H) unzipsfx$O: unzip.c $(UNZIP_H) crypt.h unzvers.h consts.h # unzipsfx only @@ -342,6 +343,11 @@ match_$O: match.c $(UNZIP_H) # unzips $(CC) -c $(CF) -DSFX match_.c $(RM) match_.c +xattr_$O: xattr.c $(UNZIP_H) # unzipsfx only + -$(CP) xattr.c xattr_.c + $(CC) -c $(CF) -DSFX xattr_.c + $(RM) xattr_.c + process_$O: process.c $(UNZIP_H) # unzipsfx only -$(CP) process.c process_.c $(CC) -c $(CF) -DSFX process_.c diff -urpN unzip-5.51.orig/process.c unzip-5.51/process.c --- unzip-5.51.orig/process.c 2005-09-08 14:25:57.000000000 -0500 +++ unzip-5.51/process.c 2005-10-24 16:09:09.000000000 -0500 @@ -1300,15 +1300,22 @@ int process_local_file_hdr(__G) /* re /*******************************/ /* Function ef_scan_for_izux() */ /*******************************/ - +#ifdef USE_EF_XATTR +unsigned ef_scan_for_izux(ef_buf, ef_len, ef_is_c, dos_mdatetime, + z_utim, z_uidgid, z_xattr) +#else unsigned ef_scan_for_izux(ef_buf, ef_len, ef_is_c, dos_mdatetime, z_utim, z_uidgid) +#endif ZCONST uch *ef_buf; /* buffer containing extra field */ unsigned ef_len; /* total length of extra field */ int ef_is_c; /* flag indicating "is central extra field" */ ulg dos_mdatetime; /* last_mod_file_date_time in DOS format */ iztimes *z_utim; /* return storage: atime, mtime, ctime */ ush *z_uidgid; /* return storage: uid and gid */ +#ifdef USE_EF_XATTR + izxattr *z_xattr; /* return storage: xattr names, values, lens, count */ +#endif { unsigned flags = 0; unsigned eb_id; @@ -1342,6 +1349,12 @@ unsigned ef_scan_for_izux(ef_buf, ef_len if (ef_len == 0 || ef_buf == NULL || (z_utim == 0 && z_uidgid == NULL)) return 0; +#ifdef USE_EF_XATTR + if (z_xattr == NULL) + return 0; + z_xattr->count=0; +#endif + TTrace((stderr,"\nef_scan_for_izux: scanning extra field of length %u\n", ef_len)); @@ -1358,6 +1371,56 @@ unsigned ef_scan_for_izux(ef_buf, ef_len } switch (eb_id) { +#ifdef USE_EF_XATTR + case EF_XATTR: + z_xattr->count=eb_len; + if (z_xattr->count > 0) { + ef_buf += EB_HEADSIZE; + ef_len -= EB_HEADSIZE; + eb_id = makeword(EB_ID + ef_buf); + } else { + break; + } + case EF_XA_NAME: + if (z_xattr->count > 0) { + ef_buf += EB_HEADSIZE; + ef_len -= EB_HEADSIZE; + if ((z_xattr->xa_name=malloc(ef_len)) == (char *)NULL) { + Info(slide, 0x401, ((char *)slide, + LoadFarString(CannotAllocateBuffers))); + return 0; + } + z_xattr->xa_name_len=copy_xattr(ef_buf, z_xattr->xa_name, z_xattr->count); + if (z_xattr->xa_name_len < 0) { + TTrace((stderr, + " XATTR name error; ignore e.f.!\n")); + break; /* stop scanning this field */ + } + ef_buf += z_xattr->xa_name_len; + ef_len -= z_xattr->xa_name_len; + } else { + break; + } + case EF_XA_VALUE: + if (z_xattr->count > 0) { + ef_buf += EB_HEADSIZE; + ef_len -= EB_HEADSIZE; + if ((z_xattr->xa_value=malloc(ef_len)) == (char *)NULL) { + Info(slide, 0x401, ((char *)slide, + LoadFarString(CannotAllocateBuffers))); + return 0; + } + z_xattr->xa_value_len=copy_xattr(ef_buf, z_xattr->xa_value, z_xattr->count); + if (z_xattr->xa_value_len <= 0) { + TTrace((stderr, + " XATTR value error; ignore e.f.!\n")); + break; /* stop scanning this field */ + } + ef_buf += z_xattr->xa_value_len; + ef_len -= z_xattr->xa_value_len; + } + break; +#endif case EF_TIME: flags &= ~0x0ff; /* ignore previous IZUNIX or EF_TIME fields */ have_new_type_eb = TRUE; diff -urpN unzip-5.51.orig/unix/Makefile unzip-5.51/unix/Makefile --- unzip-5.51.orig/unix/Makefile 2005-09-08 14:25:57.000000000 -0500 +++ unzip-5.51/unix/Makefile 2005-10-24 16:09:09.000000000 -0500 @@ -81,14 +81,14 @@ CRC32 = crc32 OSDEP_H = # object files -OBJS1 = unzip$O $(CRC32)$O crctab$O crypt$O envargs$O explode$O +OBJS1 = unzip$O $(CRC32)$O crctab$O crypt$O envargs$O explode$O xattr$O OBJS2 = extract$O fileio$O globals$O inflate$O list$O match$O OBJS3 = process$O ttyio$O unreduce$O unshrink$O zipinfo$O OBJS = $(OBJS1) $(OBJS2) $(OBJS3) $M$O LOBJS = $(OBJS) OBJSDLL = $(OBJS:.o=.pic.o) api.pic.o OBJX = unzipsfx$O $(CRC32)$O crctab_$O crypt_$O extract_$O fileio_$O \ - globals_$O inflate_$O match_$O process_$O ttyio_$O $M_$O + globals_$O inflate_$O match_$O process_$O ttyio_$O xattr_$O $M_$O LOBJX = $(OBJX) OBJF = funzip$O $(CRC32)$O cryptf$O globalsf$O inflatef$O ttyiof$O #OBJS_OS2 = $(OBJS1:.o=.obj) $(OBJS2:.o=.obj) os2.obj @@ -300,6 +300,7 @@ ttyio$O: ttyio.c $(UNZIP_H) zip.h crypt. unreduce$O: unreduce.c $(UNZIP_H) unshrink$O: unshrink.c $(UNZIP_H) unzip$O: unzip.c $(UNZIP_H) crypt.h unzvers.h consts.h +xattr$O: xattr.c $(UNZIP_H) zipinfo$O: zipinfo.c $(UNZIP_H) unzipsfx$O: unzip.c $(UNZIP_H) crypt.h unzvers.h consts.h # unzipsfx only @@ -342,6 +343,11 @@ match_$O: match.c $(UNZIP_H) # unzips $(CC) -c $(CF) -DSFX match_.c $(RM) match_.c +xattr_$O: xattr.c $(UNZIP_H) # unzipsfx only + -$(CP) xattr.c xattr_.c + $(CC) -c $(CF) -DSFX xattr_.c + $(RM) xattr_.c + process_$O: process.c $(UNZIP_H) # unzipsfx only -$(CP) process.c process_.c $(CC) -c $(CF) -DSFX process_.c diff -urpN unzip-5.51.orig/unix/unix.c unzip-5.51/unix/unix.c --- unzip-5.51.orig/unix/unix.c 2005-09-08 14:25:57.000000000 -0500 +++ unzip-5.51/unix/unix.c 2005-10-24 16:09:09.000000000 -0500 @@ -83,6 +83,7 @@ typedef struct uxdirattr { /* struc int have_uidgid; /* flag */ ush uidgid[2]; char fnbuf[1]; /* buffer stub for directory name */ + izxattr z_xattr; /* struct for xattr names and values */ } uxdirattr; #define UxAtt(d) ((uxdirattr *)d) /* typecast shortcut */ #endif /* SET_DIR_ATTRIB */ @@ -932,12 +933,13 @@ int mkdir(path, mode) #if (!defined(MTS) || defined(SET_DIR_ATTRIB)) -static int get_extattribs OF((__GPRO__ iztimes *pzt, ush z_uidgid[2])); +static int get_extattribs OF((__GPRO__ iztimes *pzt, ush z_uidgid[2], izxattr *pzxattr)); -static int get_extattribs(__G__ pzt, z_uidgid) +static int get_extattribs(__G__ pzt, z_uidgid, pzxattr) __GDEF iztimes *pzt; ush z_uidgid[2]; + izxattr *pzxattr; { /*--------------------------------------------------------------------------- Convert from MSDOS-format local time and date to Unix-format 32-bit GMT @@ -957,7 +959,13 @@ static int get_extattribs(__G__ pzt, z_u #else pzt, #endif - z_uidgid) : 0); + z_uidgid, +#ifdef USE_EF_XATTR + pzxattr) : 0); +#else + NULL) : 0); +#endif + if (eb_izux_flg & EB_UT_FL_MTIME) { TTrace((stderr, "\nget_extattribs: Unix e.f. modif. time = %ld\n", pzt->mtime)); @@ -1000,7 +1008,14 @@ void close_outfile(__G) /* GRR: chang ztimbuf t2; /* modtime, actime */ } zt; ush z_uidgid[2]; + izxattr z_xattr; int have_uidgid_flg; + int rc=0; + char *name; + char *value; + int i; + int value_len; + int largest_value_len=0; fchmod(fileno(G.outfile), 0400); @@ -1090,7 +1105,7 @@ void close_outfile(__G) /* GRR: chang } #endif - have_uidgid_flg = get_extattribs(__G__ &(zt.t3), z_uidgid); + have_uidgid_flg = get_extattribs(__G__ &(zt.t3), z_uidgid, &z_xattr); /* if -X option was specified and we have UID/GID info, restore it */ if (have_uidgid_flg) { @@ -1108,6 +1123,54 @@ void close_outfile(__G) /* GRR: chang } } +#ifdef USE_EF_XATTR +/* if -E option was specified attempt to restore extended attribute info */ + if (uO.E_flag && (!have_uidgid_flg)) { + Info(slide, 0x201, ((char *)slide, + " (warning) unable to restore extended attributes for %s\n", FnFilter1(G.filename))); + } + if (uO.E_flag && have_uidgid_flg) { + /* Restore extended attributes info */ + if (z_xattr.count > 0) { + /* Need to figure out the largest value_len before calling malloc */ + for (i=1; i<=z_xattr.count; i++) { + name = get_xattr_name(z_xattr.xa_name, z_xattr.xa_name_len, i); + value_len=getxattr(z_xattr.xa_name, name, value, 0); + if (value_len > largest_value_len) + largest_value_len = value_len; + } + if ((value = malloc(largest_value_len+1)) == (char *)NULL) { + Info(slide, 0x201, ((char *)slide, + "warning: xattr (%s) failed: no mem\n", + FnFilter1(G.filename))); + return; + } else { + /* Set all xattr name and value pairs */ + for (i=1; i<=z_xattr.count; i++) { + name = get_xattr_name(z_xattr.xa_name, z_xattr.xa_name_len, i); + if (name == (char *) NULL) { + Info(slide, 0x201, ((char *)slide, + " (warning) cannot restore extended attributes for %s\n", FnFilter1(G.filename))); + } + value = get_xattr_value(z_xattr.xa_value, z_xattr.xa_value_len, i); + if (value == (char *) NULL) { + Info(slide, 0x201, ((char *)slide, + " (warning) cannot restore extended attributes for %s\n", FnFilter1(G.filename))); + } + rc = setxattr(G.filename, name, value, strlen(value), 0); + if (rc != 0) { + Info(slide, 0x201, ((char *)slide, + " (warning) cannot restore extended attributes for %s\n", FnFilter1(G.filename))); + } + } + } + } else { + Info(slide, 0x201, ((char *)slide, + " (warning) cannot restore extended attributes for %s\n", FnFilter1(G.filename))); + } + } +#endif + /* set the file's access and modification times */ if (utime(G.filename, &(zt.t2))) { #ifdef AOS_VS @@ -1160,7 +1223,7 @@ int defer_dir_attribs(__G__ pd) d_entry->perms = G.pInfo->file_attr; d_entry->have_uidgid = get_extattribs(__G__ &(d_entry->u.t3), - d_entry->uidgid); + d_entry->uidgid, &(d_entry->z_xattr)); return PK_OK; } /* end function defer_dir_attribs() */ diff -urpN unzip-5.51.orig/unix/unxcfg.h unzip-5.51/unix/unxcfg.h --- unzip-5.51.orig/unix/unxcfg.h 2005-09-08 14:25:57.000000000 -0500 +++ unzip-5.51/unix/unxcfg.h 2005-10-24 16:09:09.000000000 -0500 @@ -122,6 +122,8 @@ #endif #define RESTORE_UIDGID +#define USE_EF_XATTR + /* Static variables that we have to add to Uz_Globs: */ #define SYSTEM_SPECIFIC_GLOBALS \ int created_dir, renamed_fullpath;\ diff -urpN unzip-5.51.orig/unzip.c unzip-5.51/unzip.c --- unzip-5.51.orig/unzip.c 2005-09-08 14:25:57.000000000 -0500 +++ unzip-5.51/unzip.c 2005-10-24 16:09:09.000000000 -0500 @@ -143,6 +143,8 @@ static ZCONST char Far InvalidOptionsMsg -fn or any combination of -c, -l, -p, -t, -u and -v options invalid\n"; static ZCONST char Far IgnoreOOptionMsg[] = "caution: both -n and -o specified; ignoring -o\n"; +static ZCONST char Far InvalidEModifierMsg[] = "error:\ + -E modifier cannot be used without -X modifier\n"; /* usage() strings */ #ifndef SFX @@ -238,12 +240,30 @@ M pipe through \"more\" pager #else /* !VMS */ #ifdef BEO_UNX static ZCONST char Far local2[] = " -X restore UID/GID info"; +#ifdef USE_EF_XATTR +#ifdef MORE + static ZCONST char Far local3[] = " \ +-E restore extended attributes -M pipe through \"more\" pager\n"; +#else /* !MORE */ + static ZCONST char Far local3[] = " \ +-E restore extended attributes\n"; +#endif +#else /* !USE_EF_XATTR */ +#ifdef MORE + static ZCONST char Far local3[] = "\ + -M pipe through \"more\" pager\n"; +#else /* !MORE */ + static ZCONST char Far local3[] = "\n"; +#endif +#endif +/* #ifdef MORE static ZCONST char Far local3[] = "\ -M pipe through \"more\" pager\n"; #else static ZCONST char Far local3[] = "\n"; #endif +*/ #else /* !BEO_UNX */ #ifdef TANDEM static ZCONST char Far local2[] = "\ @@ -1222,6 +1242,15 @@ int uz_opts(__G__ pargc, pargv) } break; #endif /* MACOS */ +#ifdef UNIX + case ('E'): /* -E [UNIX] restore extended attributes */ + if( negative ) { + uO.E_flag = FALSE, negative = 0; + } else { + uO.E_flag = TRUE; + } + break; +#endif /* MACOS */ case ('f'): /* "freshen" (extract only newer files) */ if (negative) uO.fflag = uO.uflag = FALSE, negative = 0; @@ -1521,6 +1550,13 @@ opts_done: /* yes, very ugly...but only Info(slide, 0x401, ((char *)slide, LoadFarString(InvalidOptionsMsg))); error = TRUE; } +#ifdef UNIX + if (uO.E_flag && (!uO.X_flag)) + { + Info(slide, 0x401, ((char *)slide, LoadFarString(InvalidEModifierMsg))); + error = TRUE; + } +#endif if (uO.aflag > 2) uO.aflag = 2; #ifdef VMS diff -urpN unzip-5.51.orig/unzip.h unzip-5.51/unzip.h --- unzip-5.51.orig/unzip.h 2005-09-08 14:25:57.000000000 -0500 +++ unzip-5.51/unzip.h 2005-10-24 16:09:09.000000000 -0500 @@ -438,6 +438,9 @@ typedef struct _UzpOpts { #ifdef MACOS int E_flag; /* -E: [MacOS] show Mac extra field during restoring */ #endif +#ifdef UNIX + int E_flag; /* -E: [Unix] restore extended attributes */ +#endif int fflag; /* -f: "freshen" (extract only newer files) */ #if (defined(RISCOS) || defined(ACORN_FTYPE_NFS)) int acorn_nfs_ext; /* -F: RISC OS types & NFS filetype extensions */ @@ -571,6 +574,7 @@ typedef struct central_directory_file_he #define PK_FIND 11 /* no files found */ #define PK_DISK 50 /* disk full */ #define PK_EOF 51 /* unexpected EOF */ +#define PK_XATTR 52 /* extended attributes error */ #define IZ_CTRLC 80 /* user hit ^C to terminate */ #define IZ_UNSUP 81 /* no files found: all unsup. compr/encrypt. */ diff -urpN unzip-5.51.orig/unzpriv.h unzip-5.51/unzpriv.h --- unzip-5.51.orig/unzpriv.h 2005-09-08 14:25:57.000000000 -0500 +++ unzip-5.51/unzpriv.h 2005-10-24 16:09:09.000000000 -0500 @@ -1433,6 +1433,9 @@ #define EF_THEOSO 0x4854 /* old Theos port */ #define EF_MD5 0x4b46 /* Fred Kantor's MD5 ("FK") */ #define EF_ASIUNIX 0x756e /* ASi's Unix ("nu") */ +#define EF_XATTR 0x4158 /* XATTR ("XA") */ +#define EF_XA_NAME 0x4e58 /* XATTR NAME ("XN") */ +#define EF_XA_VALUE 0x5658 /* XATTR VALUE ("XV") */ #define EB_HEADSIZE 4 /* length of extra field block header */ #define EB_ID 0 /* offset of block ID in header */ @@ -1459,6 +1462,8 @@ #define EB_UT_FL_ATIME (1 << 1) /* atime present */ #define EB_UT_FL_CTIME (1 << 2) /* ctime present */ +#define EB_XA_MINLEN 4 /* minimal XA size */ + #define EB_FLGS_OFFS 4 /* offset of flags area in generic compressed extra field blocks (BEOS, MAC, and others) */ #define EB_OS2_HLEN 4 /* size of OS2/ACL compressed data header */ @@ -1576,6 +1581,14 @@ typedef struct iztimes { time_t ctime; /* used for creation time; NOT same as st_ctime */ } iztimes; +typedef struct izxattr { + char *xa_name; /* xattr names list */ + char *xa_value; /* xattr values list */ + ssize_t xa_name_len; /* size of xa_names list */ + ssize_t xa_value_len; /* size of xa_value list */ + int count; /* number of xattr name and value pairs */ +} izxattr; + #ifdef SET_DIR_ATTRIB typedef struct direntry { /* head of system-specific struct holding */ struct direntry *next; /* defered directory attributes info */ @@ -1812,7 +1825,12 @@ int get_cdir_ent OF((__G int process_local_file_hdr OF((__GPRO)); unsigned ef_scan_for_izux OF((ZCONST uch *ef_buf, unsigned ef_len, int ef_is_c, ulg dos_mdatetime, +#ifdef USE_EF_XATTR + iztimes *z_utim, ush *z_uidgid, + izxattr *z_xattr)); +#else iztimes *z_utim, ush *z_uidgid)); +#endif #if (defined(RISCOS) || defined(ACORN_FTYPE_NFS)) zvoid *getRISCOSexfield OF((ZCONST uch *ef_buf, unsigned ef_len)); #endif @@ -1850,6 +1868,15 @@ void fnprint OF((__G #endif /* !SFX */ /*--------------------------------------------------------------------------- + Functions in xattr.c: + ---------------------------------------------------------------------------*/ + +int get_xattr_count(char *xa_list, int xa_list_size); +char * get_xattr_name(char *xa_list, int xa_list_size, int pair); +char * get_xattr_value(char *xa_list, int xa_list_size, int pair); +int copy_xattr(char *xa_list, char *new_list, int pair); + +/*--------------------------------------------------------------------------- Functions in fileio.c: ---------------------------------------------------------------------------*/ diff -urpN unzip-5.51.orig/xattr.c unzip-5.51/xattr.c --- unzip-5.51.orig/xattr.c 1969-12-31 18:00:00.000000000 -0600 +++ unzip-5.51/xattr.c 2005-10-24 16:12:01.000000000 -0500 @@ -0,0 +1,127 @@ +/* +*/ +/* xattr.c + * + * Author: Debora Velarde + * Created: Sept 14, 2005 + */ + + +#define __XATTR_C /* identifies this source module */ +#define UNZIP_INTERNAL +#include "unzip.h" + +int get_xattr_count(char *xa_list, int xa_list_size) +{ +/* xattr names have the form name1.name2 */ +/* A file can have any number of xattr name pairs */ +/* This function returns the number of name pairs found */ +/* If list passed in is NULL or list size is less than 1 + function retunrs 0 */ + + int i=0; + int p=0; + + if ( (xa_list == (char *) NULL) || (xa_list_size < 1)) + return 0; + + + while (i < xa_list_size) { + if ( xa_list[i] != '\0') { + i++; + } else { + i++; //move index to one past \0 + p++; + } + } + + return p; +} + +char * get_xattr_name(char *xa_list, int xa_list_size, int pair) +{ +/* xattr names have the form name1.name2 */ +/* A file can have any number of xattr name pairs */ +/* This function returns a pointer to the specified name pair */ +/* If list is NULL or size or pair are less than 1, then + function returns NULL */ + + int i=0; + int p=1; + char *tmp; + + tmp=NULL; + + if ( (xa_list == (char *) NULL) || (xa_list_size < 1) || (pair < 1) ) + return NULL; + + while ( (i < xa_list_size) && ( p != pair) ) { + if ( xa_list[i] != '\0') { + i++; + } else { + i++; //move index to one past \0 + p++; + } + } + + if ( (p==pair) && (i < xa_list_size) ) + tmp=&xa_list[i]; + + return tmp; +} + +char * get_xattr_value(char *xa_list, int xa_list_size, int pair) +{ +/* A file can have any number of xattr name and value pairs */ +/* This function returns a pointer to the specified value pair */ +/* If list is NULL or size or pair are less than 1, then + function returns NULL */ + + int i=0; + int p=1; + char *tmp; + + tmp=NULL; + + if ( (xa_list == (char *) NULL) || (xa_list_size < 1) || (pair < 1) ) + return NULL; + + while ( (i < xa_list_size) && ( p != pair) ) { + if ( xa_list[i] != '\0') { + i++; + } else { + i++; //move index to one past \0 + p++; + } + } + + if ( (p==pair) && (i < xa_list_size) ) + tmp=&xa_list[i]; + + return tmp; +} + +int copy_xattr(char *xa_list, char *new_list, int pair) +{ +/* A file can have any number of xattr name and value pairs */ +/* This function copies all the names or value from xa_list to new_list */ +/* This function returns the size of new_list */ +/* If either list being copied or new list is NULL, then retunrs -1 */ +/* If pair is less than 1 returns -1 */ + + int i=0; + int p=0; + + if ( (xa_list == (char *) NULL) || (new_list == (char *) NULL) || (pair < 1) ) + return -1; + + while ( p < pair ) { + new_list[i] = xa_list[i]; + if ( xa_list[i] == '\0') { + p++; + } + i++; + } + + return i; +} diff -urpN unzip-5.51.orig/zipinfo.c unzip-5.51/zipinfo.c --- unzip-5.51.orig/zipinfo.c 2005-09-08 14:25:57.000000000 -0500 +++ unzip-5.51/zipinfo.c 2005-10-24 16:09:09.000000000 -0500 @@ -330,6 +330,8 @@ static ZCONST char Far efMD5[] = "Fred K static ZCONST char Far efASiUnix[] = "ASi Unix"; static ZCONST char Far efTandem[] = "Tandem NSK"; static ZCONST char Far efTheos[] = "Theos"; +static ZCONST char Far efXAname[] = "xattr name"; +static ZCONST char Far efXAvalue[] = "xattr value"; static ZCONST char Far efUnknown[] = "unknown"; static ZCONST char Far OS2EAs[] = ".\n\ @@ -935,6 +937,9 @@ static int zi_long(__G__ pEndprev) /* #ifdef USE_EF_UT_TIME iztimes z_utime; #endif +#ifdef USE_EF_XATTR + izxattr z_xattr; +#endif int error, error_in_archive=PK_COOL; unsigned hostnum, hostver, extnum, extver, methnum, xattr; char workspace[12], attribs[22]; @@ -1076,7 +1081,12 @@ static int zi_long(__G__ pEndprev) /* G.tz_is_valid && #endif (ef_scan_for_izux(G.extra_field, G.crec.extra_field_length, 1, - G.crec.last_mod_dos_datetime, &z_utime, NULL) + G.crec.last_mod_dos_datetime, &z_utime, +#ifdef USE_EF_XATTR + NULL, &z_xattr) +#else + NULL) +#endif & EB_UT_FL_MTIME)) { TIMET_TO_NATIVE(z_utime.mtime) /* NOP unless MSC 7.0 or Macintosh */ @@ -1422,6 +1432,12 @@ static int zi_long(__G__ pEndprev) /* #endif ef_fieldname = efTheos; break; + case EF_XA_NAME: + ef_fieldname = efXAname; + break; + case EF_XA_VALUE: + ef_fieldname = efXAvalue; + break; default: ef_fieldname = efUnknown; break; @@ -1755,6 +1771,9 @@ static int zi_short(__G) /* return PK- iztimes z_utime; time_t *z_modtim; #endif +#ifdef USE_EF_XATTR + izxattr z_xattr; +#endif int k, error, error_in_archive=PK_COOL; unsigned hostnum, hostver, methnum, xattr; char *p, workspace[12], attribs[16]; @@ -2053,7 +2072,12 @@ static int zi_short(__G) /* return PK- G.tz_is_valid && #endif (ef_scan_for_izux(G.extra_field, G.crec.extra_field_length, 1, - G.crec.last_mod_dos_datetime, &z_utime, NULL) + G.crec.last_mod_dos_datetime, &z_utime, +#ifdef USE_EF_XATTR + NULL, &z_xattr) +#else + NULL) +#endif & EB_UT_FL_MTIME) ? &z_utime.mtime : NULL; TIMET_TO_NATIVE(z_utime.mtime) /* NOP unless MSC 7.0 or Macintosh */ From dwmw2 at infradead.org Tue Oct 25 13:53:17 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 25 Oct 2005 14:53:17 +0100 Subject: [redhat-lspp] Fedora on P Series should be working In-Reply-To: <4357B6E7.7070406@redhat.com> References: <4357B6E7.7070406@redhat.com> Message-ID: <1130248397.6932.322.camel@baythorne.infradead.org> On Thu, 2005-10-20 at 11:25 -0400, Daniel J Walsh wrote: > Talked to Paul Nasrat and he states that most P-Series platforms > should be working with today's Rawhide. He has some fixes that will > go in tonight to fix a couple of problems also. The problems in rawhide have only really been with the installer. Installing Fedora Core 4 (from ftp://zeniv.uk.linux.org/pub/people/dwmw2/fc4-pegasos if not from the original release, which had some problems at least with HVC console) and the using yum to update to rawhide should have been working regardless. -- dwmw2 From ltcgcw at us.ibm.com Tue Oct 25 14:18:44 2005 From: ltcgcw at us.ibm.com (George C. Wilson) Date: Tue, 25 Oct 2005 09:18:44 -0500 Subject: [redhat-lspp] Fedora on P Series should be working In-Reply-To: <1130248397.6932.322.camel@baythorne.infradead.org> References: <4357B6E7.7070406@redhat.com> <1130248397.6932.322.camel@baythorne.infradead.org> Message-ID: <20051025141844.GA1487@us.ibm.com> On Tue, Oct 25, 2005 at 02:53:17PM +0100, David Woodhouse wrote: > The problems in rawhide have only really been with the installer. > Installing Fedora Core 4 (from > ftp://zeniv.uk.linux.org/pub/people/dwmw2/fc4-pegasos if not from the > original release, which had some problems at least with HVC console) and > the using yum to update to rawhide should have been working regardless. > > -- > dwmw2 We had some success doing that with Dustin's help. We hit the console issue, plus our internal FC4 repo turned out to be incomplete. I think Debora's LPAR is running FC4 yum updated to rawhide. Paul was very helpful on IRC last week, and was able to recreate and fix at least one installer issue I know of. I got rawhide installed on my LPAR over the weekend except for yaboot, which I manually installed. -- George Wilson IBM Linux Technology Center From dwalsh at redhat.com Tue Oct 25 16:01:53 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 25 Oct 2005 12:01:53 -0400 Subject: [redhat-lspp] selinux-policy-mls is now part of Fedora Core. In-Reply-To: <1129906258.2651.71.camel@kirkland3.austin.ibm.com> References: <1129906258.2651.71.camel@kirkland3.austin.ibm.com> Message-ID: <435E56F1.50000@redhat.com> -- From paul.moore at hp.com Tue Oct 25 18:28:09 2005 From: paul.moore at hp.com (Paul Moore) Date: Tue, 25 Oct 2005 14:28:09 -0400 Subject: [redhat-lspp] [RFC] A Proposal for CIPSO on Linux (again) Message-ID: <435E7939.2070007@hp.com> After speaking with a few people who currently run multi-level networks and who are familiar with all that goes into certifying them at the higher levels I have come to the conclusion that while the IPsec based approach to labeled networking may be suitable for an LSPP evaluation it may not be suitable for actual use in an existing multi-level network. The two main reasons appear to be a real desire to have explicit packet labeling and interoperability with existing network protocols already in use. In order to satisfy these two requirements I propose implementing CIPSO on Linux (see attached document). While just the thought of CIPSO and Linux may bring about headaches in some of the people on the list, I really believe that having a workable CIPSO implementation on Linux would open doors that might otherwise be closed to us. I understand that CIPSO support has already been attempted, and unfortunately rejected by the greater kernel netdev community; however, I have taken the original feedback from DaveM into consideration and arrived at what I think is a reasonable compromise. For example, my proposal does not involve any new LSM hooks, the only changes to the base network stack would be some updates to ip_options.c (to make it CIPSO aware) and a new netfilter module. I believe all of the access decisions and packet labeling can be done using the existing LSM hooks. I would greatly appreciate any feedback you can offer. Thanks, -- . paul moore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . paul.moore at hp.com hewlett packard . (603) 884-5056 linux security -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cipsolinux_notes_external.txt URL: From chrisw at osdl.org Tue Oct 25 18:40:32 2005 From: chrisw at osdl.org (Chris Wright) Date: Tue, 25 Oct 2005 11:40:32 -0700 Subject: [redhat-lspp] [RFC] A Proposal for CIPSO on Linux (again) In-Reply-To: <435E7939.2070007@hp.com> References: <435E7939.2070007@hp.com> Message-ID: <20051025184032.GY5856@shell0.pdx.osdl.net> * Paul Moore (paul.moore at hp.com) wrote: > I understand that CIPSO support has already been attempted, and > unfortunately rejected by the greater kernel netdev community; however, > I have taken the original feedback from DaveM into consideration and > arrived at what I think is a reasonable compromise. For example, my > proposal does not involve any new LSM hooks, the only changes to the > base network stack would be some updates to ip_options.c (to make it > CIPSO aware) and a new netfilter module. I believe all of the access > decisions and packet labeling can be done using the existing LSM hooks. > I would greatly appreciate any feedback you can offer. What's the point? CIPSO is meaningless w/out packet header integrity, which requires encryption, which looks what Trent is working on now. Also do you handle fragments, and encapsulation? thanks, -chris From ltcgcw at us.ibm.com Tue Oct 25 18:45:32 2005 From: ltcgcw at us.ibm.com (George Wilson) Date: Tue, 25 Oct 2005 13:45:32 -0500 Subject: [redhat-lspp] [Reminder] Open LSPP Development Telecon Message-ID: <1130265932.21689.151.camel@ea.austin.ibm.com> IBM hosts a telecon every Wednesday morning to discuss the development issues surrounding Linux LSPP certification. The call is open to all who have something to bring to the effort. If you would like to participate and are not already an attendee, please reply directly to me with your contact information. I will respond with an invitation. Please note that the number of attendees may be limited by our call center's restrictions on maximum lines per conference. -- George Wilson IBM Linux Technology Center From ltcgcw at us.ibm.com Tue Oct 25 19:07:40 2005 From: ltcgcw at us.ibm.com (George Wilson) Date: Tue, 25 Oct 2005 14:07:40 -0500 Subject: [redhat-lspp] [RFC] A Proposal for CIPSO on Linux (again) In-Reply-To: <435E7939.2070007@hp.com> References: <435E7939.2070007@hp.com> Message-ID: <1130267260.21689.171.camel@ea.austin.ibm.com> On Tue, 2005-10-25 at 14:28 -0400, Paul Moore wrote: > After speaking with a few people who currently run multi-level networks > and who are familiar with all that goes into certifying them at the > higher levels I have come to the conclusion that while the IPsec based > approach to labeled networking may be suitable for an LSPP evaluation it > may not be suitable for actual use in an existing multi-level network. > The two main reasons appear to be a real desire to have explicit > packet labeling and interoperability with existing network protocols > already in use. In order to satisfy these two requirements I propose > implementing CIPSO on Linux (see attached document). While just the > thought of CIPSO and Linux may bring about headaches in some of the > people on the list, I really believe that having a workable CIPSO > implementation on Linux would open doors that might otherwise be closed > to us. Our team seriously considered resurrecting the CIPSO patch. The main argument against it was its impact on mainline gigabit ethernet performance. IPsec already adds so much overhead that labeling is a negligible addition. Moreover, it was pointed out that labels w/o encryption can help an attacker determine which traffic is most interesting. Please also note that SAs aren't really implicit--they are in effect labels that are mapped to SELinux labels. It may be interesting to provide a CIPSO compatibility layer to interoperate with TSOL. But couldn't a trusted router/guard be used to accomplish that? -- George Wilson IBM Linux Technology Center From paul.moore at hp.com Tue Oct 25 19:09:35 2005 From: paul.moore at hp.com (Paul Moore) Date: Tue, 25 Oct 2005 15:09:35 -0400 Subject: [redhat-lspp] [RFC] A Proposal for CIPSO on Linux (again) In-Reply-To: <20051025184032.GY5856@shell0.pdx.osdl.net> References: <435E7939.2070007@hp.com> <20051025184032.GY5856@shell0.pdx.osdl.net> Message-ID: <435E82EF.90606@hp.com> Chris Wright wrote: > * Paul Moore (paul.moore at hp.com) wrote: > >>I understand that CIPSO support has already been attempted, and >>unfortunately rejected by the greater kernel netdev community; however, >>I have taken the original feedback from DaveM into consideration and >>arrived at what I think is a reasonable compromise. For example, my >>proposal does not involve any new LSM hooks, the only changes to the >>base network stack would be some updates to ip_options.c (to make it >>CIPSO aware) and a new netfilter module. I believe all of the access >>decisions and packet labeling can be done using the existing LSM hooks. >> I would greatly appreciate any feedback you can offer. > > What's the point? CIPSO is meaningless w/out packet header integrity, > which requires encryption, which looks what Trent is working on now. > Also do you handle fragments, and encapsulation? > > thanks, > -chris Standard IPsec AH headers can provide header integrity since the CIPSO IP option should be considered an immutable option. As far as fragmentation goes, please read my original proposal as I am thinking of adding the CIPSO IP option to the socket and letting the normal network stack processing label the packets (from what I can tell it should handle fragments correctly, i.e. attach the option to each fragment). Regarding encapsulation, encapsulation within what? Another IPv4 header? An IPv6 header? The point of attempting this again is because there are large customers who are running multi-level networks using CIPSO and so far the feedback we have received from them is that implicit packet labeling using non-standard extensions to IKE/IPsec is not really an option. Having CIPSO as an option for a MLS Linux system means we can offer users/customers a solution which they can plug into their existing networks. Also, please keep in mind that my CIPSO proposal and Trent's IPsec approach are not mutually exclusive. Both can co-exist in a running kernel. -- . paul moore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . paul.moore at hp.com hewlett packard . (603) 884-5056 linux security From paul.moore at hp.com Tue Oct 25 19:22:08 2005 From: paul.moore at hp.com (Paul Moore) Date: Tue, 25 Oct 2005 15:22:08 -0400 Subject: [redhat-lspp] [RFC] A Proposal for CIPSO on Linux (again) In-Reply-To: <1130267260.21689.171.camel@ea.austin.ibm.com> References: <435E7939.2070007@hp.com> <1130267260.21689.171.camel@ea.austin.ibm.com> Message-ID: <435E85E0.80107@hp.com> George Wilson wrote: > On Tue, 2005-10-25 at 14:28 -0400, Paul Moore wrote: > >>After speaking with a few people who currently run multi-level networks >>and who are familiar with all that goes into certifying them at the >>higher levels I have come to the conclusion that while the IPsec based >>approach to labeled networking may be suitable for an LSPP evaluation it >> may not be suitable for actual use in an existing multi-level network. >> The two main reasons appear to be a real desire to have explicit >>packet labeling and interoperability with existing network protocols >>already in use. In order to satisfy these two requirements I propose >>implementing CIPSO on Linux (see attached document). While just the >>thought of CIPSO and Linux may bring about headaches in some of the >>people on the list, I really believe that having a workable CIPSO >>implementation on Linux would open doors that might otherwise be closed >>to us. > > Our team seriously considered resurrecting the CIPSO patch. The main > argument against it was its impact on mainline gigabit ethernet > performance. IPsec already adds so much overhead that labeling is a > negligible addition. Moreover, it was pointed out that labels w/o > encryption can help an attacker determine which traffic is most > interesting. Please also note that SAs aren't really implicit--they are > in effect labels that are mapped to SELinux labels. It may be > interesting to provide a CIPSO compatibility layer to interoperate with > TSOL. But couldn't a trusted router/guard be used to accomplish that? > First off, the old CIPSO patch had more of a throughput hit than running IPsec? I never ran the old patch on a system or saw any benchmarks so I'll have to take your word for it, but I just find that very surprising. Regardless of the previous implementation I think the proposal I presented such have performance much higher than that of IPsec. As far as putting the MLS Linux system behind a trusted router/guard, this would require the guard to understand the IPsec/IKE extensions or it would effectively turn the multi-level Linux host into a single level network host - something which goes against what we are trying to acomplish here. -- . paul moore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . paul.moore at hp.com hewlett packard . (603) 884-5056 linux security From casey at schaufler-ca.com Tue Oct 25 19:49:10 2005 From: casey at schaufler-ca.com (schaufler-ca.com - Casey Schaufler) Date: Tue, 25 Oct 2005 15:49:10 -0400 Subject: Fwd: Fwd: Re: [redhat-lspp] [RFC] A Proposal for CIPSO on Linux (again) Message-ID: <200510251949.j9PJnAco026941@luminouswebdesign.com> --- Chris Wright wrote: > What?s the point? CIPSO is meaningless w/out packet > header integrity And it's not a hamburger without the pickle. The reality is that CIPSO systems have been deployed since the last 1980's. I understand that there are people out there who can't grasp the notion of a security feature that does not use encryption. That notion killed TSIG. There are numerous environments where CIPSO is just fine. > which requires encryption, which looks what Trent is > working on now. Yeah, whatever. > Also do you handle fragments, and encapsulation? You don't. You don't need to if you do it right. From joe at nall.com Tue Oct 25 19:54:04 2005 From: joe at nall.com (Joe Nall) Date: Tue, 25 Oct 2005 14:54:04 -0500 Subject: [redhat-lspp] [RFC] A Proposal for CIPSO on Linux (again) In-Reply-To: <20051025184032.GY5856@shell0.pdx.osdl.net> References: <435E7939.2070007@hp.com> <20051025184032.GY5856@shell0.pdx.osdl.net> Message-ID: On Oct 25, 2005, at 1:40 PM, Chris Wright wrote: > * Paul Moore (paul.moore at hp.com) wrote: > >> I understand that CIPSO support has already been attempted, and >> unfortunately rejected by the greater kernel netdev community; >> however, >> I have taken the original feedback from DaveM into consideration and >> arrived at what I think is a reasonable compromise. For example, my >> proposal does not involve any new LSM hooks, the only changes to the >> base network stack would be some updates to ip_options.c (to make it >> CIPSO aware) and a new netfilter module. I believe all of the access >> decisions and packet labeling can be done using the existing LSM >> hooks. >> I would greatly appreciate any feedback you can offer. >> > > What's the point? CIPSO is meaningless w/out packet header integrity, > which requires encryption, which looks what Trent is working on now. > Also do you handle fragments, and encapsulation? Encryption can be external or the connection can be point-to-point. That is how we have to do it today between our HP CMWs (a SecureWare based MLS OS roughly equivalent to Trusted Solaris 8). Ultimately the IPSec approach will work better for us because we will be able to address these integrity issues without our current workaround of a physically separate network with locked down switches and physical security on the fiber, switches and workstations. Having said that, CIPSO between our legacy HP CMWs and SELinux would allow us to migrate our IP based applications over time rather than as one traumatic event. It would also allow us to communicate with existing MLS thin client session servers (TSOL 8) without many single level network connections. We have about 200 seats of MLS X displays today. Given that X windows doesn't appear be part of an LSPP evaluated SELinux in the near term, CIPSO support would make it possible to upgrade our servers to SELinux and keep the existing clients until X catches up. joe From chrisw at osdl.org Tue Oct 25 20:02:03 2005 From: chrisw at osdl.org (Chris Wright) Date: Tue, 25 Oct 2005 13:02:03 -0700 Subject: [redhat-lspp] [RFC] A Proposal for CIPSO on Linux (again) In-Reply-To: <435E82EF.90606@hp.com> References: <435E7939.2070007@hp.com> <20051025184032.GY5856@shell0.pdx.osdl.net> <435E82EF.90606@hp.com> Message-ID: <20051025200203.GT7991@shell0.pdx.osdl.net> * Paul Moore (paul.moore at hp.com) wrote: > Chris Wright wrote: > Standard IPsec AH headers can provide header integrity since the CIPSO > IP option should be considered an immutable option. I guess that's my point. Using ipsec...so use ipsec ;-) > As far as > fragmentation goes, please read my original proposal as I am thinking of > adding the CIPSO IP option to the socket and letting the normal network > stack processing label the packets (from what I can tell it should > handle fragments correctly, i.e. attach the option to each fragment). Yes, I saw that with post_create hook. But didn't look too far to see that the socket label copied to every fragment, since LSM post_create by itself is not enough. Nor did I see where you protect from setsockopt to turn it off? I think the whole idea is harder to show secure, than using ipsec approach. I also didn't see how you handle raw sockets. > Regarding encapsulation, encapsulation within what? Another IPv4 > header? An IPv6 header? Either, really. But I was thinking of GRE and IP-in-IP type. Point is, I think doing it right (meaning can't undermine the protection) is what requires more invasive hooks. > The point of attempting this again is because there are large customers > who are running multi-level networks using CIPSO and so far the feedback > we have received from them is that implicit packet labeling using > non-standard extensions to IKE/IPsec is not really an option. Having > CIPSO as an option for a MLS Linux system means we can offer > users/customers a solution which they can plug into their existing networks. This is the only compelling reasoning, but it's not technical, and I think the technical issues outweigh here. The problem is the performance hit is felt too far and wide. This is processing that has to happen on every outbound and inbound packet. Inbound is certainly helped since we have security_sock_rcv_skb. > Also, please keep in mind that my CIPSO proposal and Trent's IPsec > approach are not mutually exclusive. Both can co-exist in a running kernel. *nod* thanks, -chris From chrisw at osdl.org Tue Oct 25 20:26:15 2005 From: chrisw at osdl.org (Chris Wright) Date: Tue, 25 Oct 2005 13:26:15 -0700 Subject: [redhat-lspp] [RFC] A Proposal for CIPSO on Linux (again) In-Reply-To: References: <435E7939.2070007@hp.com> <20051025184032.GY5856@shell0.pdx.osdl.net> Message-ID: <20051025202615.GZ5856@shell0.pdx.osdl.net> * Joe Nall (joe at nall.com) wrote: > Ultimately the IPSec approach will work better for us because we will > be able to address these integrity issues without our current workaround > of a physically separate network with locked down switches and physical > security on the fiber, switches and workstations. Exactly. > Having said that, CIPSO between our legacy HP CMWs and SELinux would > allow us to migrate our IP based applications over time rather than as > one traumatic event. It would also allow us to communicate with existing > MLS thin client session servers (TSOL 8) without many single level > network connections. Intermediate translation layer? Why add stuff to Linux mainline for migration only? Especially if there's cost associated with it (both runtime and maintenance). From ltcgcw at us.ibm.com Tue Oct 25 20:43:20 2005 From: ltcgcw at us.ibm.com (George Wilson) Date: Tue, 25 Oct 2005 15:43:20 -0500 Subject: [redhat-lspp] [RFC] A Proposal for CIPSO on Linux (again) In-Reply-To: <435E85E0.80107@hp.com> References: <435E7939.2070007@hp.com> <1130267260.21689.171.camel@ea.austin.ibm.com> <435E85E0.80107@hp.com> Message-ID: <1130273000.21689.236.camel@ea.austin.ibm.com> On Tue, 2005-10-25 at 15:22 -0400, Paul Moore wrote: > First off, the old CIPSO patch had more of a throughput hit than running > IPsec? I never ran the old patch on a system or saw any benchmarks so > I'll have to take your word for it, but I just find that very > surprising. Regardless of the previous implementation I think the > proposal I presented such have performance much higher than that of IPsec. > Sorry I wasn't clear. CIPSO certainly causes a lesser hit than IPsec. However, the existing CIPSO patch causes a significant performance degradation in the network main path at high throughput rates. Many folks who care about network security are going to be running IPsec anyway. So we may as well make use of IPsec SAs. Degradation is tiny, non-mainpath, and insignificant with respect to IPsec's overhead. IPsec labeling stands a far greater chance for upstream acceptance vs CIPSO. > As far as putting the MLS Linux system behind a trusted router/guard, > this would require the guard to understand the IPsec/IKE extensions or > it would effectively turn the multi-level Linux host into a single level > network host - something which goes against what we are trying to > acomplish here. Couldn't 2 guards mux/demux over private single-level networks? That would be ugly and unscalable. But it seems you could interoperate that way. A non-mainpath CIPSO implementation would allow you to route w/o single-level networks. That's not an undesirable goal from a migration point of view. But how would you get the patch upstream? -- George Wilson IBM Linux Technology Center From chrisw at osdl.org Tue Oct 25 20:48:34 2005 From: chrisw at osdl.org (Chris Wright) Date: Tue, 25 Oct 2005 13:48:34 -0700 Subject: [redhat-lspp] [RFC] A Proposal for CIPSO on Linux (again) In-Reply-To: <435E85E0.80107@hp.com> References: <435E7939.2070007@hp.com> <1130267260.21689.171.camel@ea.austin.ibm.com> <435E85E0.80107@hp.com> Message-ID: <20051025204834.GA5856@shell0.pdx.osdl.net> * Paul Moore (paul.moore at hp.com) wrote: > First off, the old CIPSO patch had more of a throughput hit than running > IPsec? I'm not sure if that's what George meant (I really don't think CIPSO throughput hit would be higher than IPSec, though). The question is more about effect on normal (hot) path that doesn't care about such stuff. That's where overhead is a big problem. > I never ran the old patch on a system or saw any benchmarks so > I'll have to take your word for it, but I just find that very > surprising. Regardless of the previous implementation I think the > proposal I presented such have performance much higher than that of IPsec. > > As far as putting the MLS Linux system behind a trusted router/guard, > this would require the guard to understand the IPsec/IKE extensions or Yes, that's the idea. It's a way to do the migration that Joe mentioned, and hopefully not burden mainline with transitional technology. thanks, -chris From paul.moore at hp.com Tue Oct 25 21:18:47 2005 From: paul.moore at hp.com (Paul Moore) Date: Tue, 25 Oct 2005 17:18:47 -0400 Subject: [redhat-lspp] [RFC] A Proposal for CIPSO on Linux (again) In-Reply-To: <20051025200203.GT7991@shell0.pdx.osdl.net> References: <435E7939.2070007@hp.com> <20051025184032.GY5856@shell0.pdx.osdl.net> <435E82EF.90606@hp.com> <20051025200203.GT7991@shell0.pdx.osdl.net> Message-ID: <435EA137.7080803@hp.com> Chris Wright wrote: > * Paul Moore (paul.moore at hp.com) wrote: > >>Chris Wright wrote: >>Standard IPsec AH headers can provide header integrity since the CIPSO >>IP option should be considered an immutable option. > > > I guess that's my point. Using ipsec...so use ipsec ;-) > Yes, but the nice thing is that if you don't want or need IPsec you don't have to use IPsec. If you need both data and label integrity as well as data confidentiality and you don't need interoperability with non-Linux hosts than Trent's IPsec extensions are ideal; for everything else CIPSO may present an attractive option to customers. Not everyone needs hmacs and encryption to ensure data integrity and confidentiality. > >>As far as >>fragmentation goes, please read my original proposal as I am thinking of >>adding the CIPSO IP option to the socket and letting the normal network >>stack processing label the packets (from what I can tell it should >>handle fragments correctly, i.e. attach the option to each fragment). > > Yes, I saw that with post_create hook. But didn't look too far to see > that the socket label copied to every fragment, since LSM post_create by > itself is not enough. Nor did I see where you protect from setsockopt > to turn it off? I think the whole idea is harder to show secure, than > using ipsec approach. I also didn't see how you handle raw sockets. > Can you point to where setting an IP option in the socket does not cause it to be set for every packet (I'm not trying to be atognistic here, I'm just trying to find something I missed - I don't have the extensive Linux stack background that some of you do)? As far as using setsockopt() to turn it off, why not simply use SELinux to restrict the application from setting socket options? I would think on a system running CIPSO would want to disallow applications from setting IP level options anyway. Also, and this should answer your raw socket question as well, the netfilter module would still be able to catch all the packets heading out of the system to ensure they were labeled with the acceptable range. > >>Regarding encapsulation, encapsulation within what? Another IPv4 >>header? An IPv6 header? > > > Either, really. But I was thinking of GRE and IP-in-IP type. Point is, > I think doing it right (meaning can't undermine the protection) is what > requires more invasive hooks. > All right, your correct in that it probably shouldn't matter but is exporting the label to the outermost protocol really what you want to do? For instance, CIPSO isn't really even defined for IPv6 (although it appears some OSs do support it, I haven't seen a packet dump yet but I suspect it is through destination options). >>The point of attempting this again is because there are large customers >>who are running multi-level networks using CIPSO and so far the feedback >>we have received from them is that implicit packet labeling using >>non-standard extensions to IKE/IPsec is not really an option. Having >>CIPSO as an option for a MLS Linux system means we can offer >>users/customers a solution which they can plug into their existing networks. > > This is the only compelling reasoning, but it's not technical, and I > think the technical issues outweigh here. The problem is the performance > hit is felt too far and wide. This is processing that has to happen on > every outbound and inbound packet. Inbound is certainly helped since > we have security_sock_rcv_skb. > Interoperability I think is a *very* compelling reason, heck, it is the only reason I bothered to spend some time and see if I could come up with a way to maybe make CIPSO work. I think the IPsec extensions offer a lot, and it would be great if some day the other big MLS OSs supported the IPsec extensions. However, that is not the case today and I think we need a option that can work alongside existing MLS solutions. Regarding performance, I just don't get your argument. Currently the only alternative we have is IPsec and I am pretty confident that a CIPSO implementation can be made to have less overhead than IPsec, even using just AH and a fast hash algorithm. >>Also, please keep in mind that my CIPSO proposal and Trent's IPsec >>approach are not mutually exclusive. Both can co-exist in a running kernel. > > *nod* At least we can agree on something ;) -- . paul moore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . paul.moore at hp.com hewlett packard . (603) 884-5056 linux security From paul.moore at hp.com Tue Oct 25 21:27:56 2005 From: paul.moore at hp.com (Paul Moore) Date: Tue, 25 Oct 2005 17:27:56 -0400 Subject: [redhat-lspp] [RFC] A Proposal for CIPSO on Linux (again) In-Reply-To: <20051025204834.GA5856@shell0.pdx.osdl.net> References: <435E7939.2070007@hp.com> <1130267260.21689.171.camel@ea.austin.ibm.com> <435E85E0.80107@hp.com> <20051025204834.GA5856@shell0.pdx.osdl.net> Message-ID: <435EA35C.8020402@hp.com> Chris Wright wrote: > * Paul Moore (paul.moore at hp.com) wrote: > >>First off, the old CIPSO patch had more of a throughput hit than running >>IPsec? > > I'm not sure if that's what George meant (I really don't think CIPSO > throughput hit would be higher than IPSec, though). The question is more > about effect on normal (hot) path that doesn't care about such stuff. > That's where overhead is a big problem. > In the case of the normal path where you don't care about packet labeling then my CIPSO proposal should only introduce a trivial amount of overhead, if any measureable difference is noticeable. The netfilter module can be unloaded and the LSM hooks detached; what you would be left with would be some minor code changes in ip_options.c which should be hit at all (other than being another missed case in a select statement). >>I never ran the old patch on a system or saw any benchmarks so >>I'll have to take your word for it, but I just find that very >>surprising. Regardless of the previous implementation I think the >>proposal I presented such have performance much higher than that of IPsec. >> >>As far as putting the MLS Linux system behind a trusted router/guard, >>this would require the guard to understand the IPsec/IKE extensions or > > Yes, that's the idea. It's a way to do the migration that Joe > mentioned, and hopefully not burden mainline with transitional > technology. But who is going to build such a guard? I doubt Sun will, they already have a working labeled network solution (CIPSO) why should they bother playing well with Linux? -- . paul moore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . paul.moore at hp.com hewlett packard . (603) 884-5056 linux security From paul.moore at hp.com Tue Oct 25 21:39:12 2005 From: paul.moore at hp.com (Paul Moore) Date: Tue, 25 Oct 2005 17:39:12 -0400 Subject: [redhat-lspp] [RFC] A Proposal for CIPSO on Linux (again) In-Reply-To: <1130273000.21689.236.camel@ea.austin.ibm.com> References: <435E7939.2070007@hp.com> <1130267260.21689.171.camel@ea.austin.ibm.com> <435E85E0.80107@hp.com> <1130273000.21689.236.camel@ea.austin.ibm.com> Message-ID: <435EA600.7090300@hp.com> George Wilson wrote: > On Tue, 2005-10-25 at 15:22 -0400, Paul Moore wrote: > >>First off, the old CIPSO patch had more of a throughput hit than running >>IPsec? I never ran the old patch on a system or saw any benchmarks so >>I'll have to take your word for it, but I just find that very >>surprising. Regardless of the previous implementation I think the >>proposal I presented such have performance much higher than that of IPsec. >> > > Sorry I wasn't clear. CIPSO certainly causes a lesser hit than IPsec. > However, the existing CIPSO patch causes a significant performance > degradation in the network main path at high throughput rates. Many > folks who care about network security are going to be running IPsec > anyway. So we may as well make use of IPsec SAs. Degradation is tiny, > non-mainpath, and insignificant with respect to IPsec's overhead. IPsec > labeling stands a far greater chance for upstream acceptance vs CIPSO. > Thanks for the clarification, I kinda thought that was the case but wanted to make sure. For those customers who want to run IPsec, or don't need interoperability with non-Linux hosts then I agree - the IPsec extensions are a good solution. Depending on the need they are probably even better than a CIPSO based solution. However, just because we don't think CIPSO is a good solution doesn't mean people aren't using it. Once again, some people do not need wire based encryption or hmacs. >>As far as putting the MLS Linux system behind a trusted router/guard, >>this would require the guard to understand the IPsec/IKE extensions or >>it would effectively turn the multi-level Linux host into a single level >>network host - something which goes against what we are trying to >>acomplish here. > > Couldn't 2 guards mux/demux over private single-level networks? That > would be ugly and unscalable. But it seems you could interoperate that > way. A non-mainpath CIPSO implementation would allow you to route w/o > single-level networks. That's not an undesirable goal from a migration > point of view. But how would you get the patch upstream? > I answered this in one of my responses to Chris so I'll refer you to my to him. However, regarding as to how I would get my patch upstream well I would probably start by sending my proposal to Dave Miller at first and let him know that I am trying to fix some of his objections to James' original patch and see what he had to say. I would assume there would be some back and forth and hopefully he would be open to seeing a new patch ... I figure just because one implementation dies a nasty death doesn't mean we have to give up - does it? I think it is worth trying again. -- . paul moore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . paul.moore at hp.com hewlett packard . (603) 884-5056 linux security From chrisw at osdl.org Tue Oct 25 22:46:06 2005 From: chrisw at osdl.org (Chris Wright) Date: Tue, 25 Oct 2005 15:46:06 -0700 Subject: [redhat-lspp] [RFC] A Proposal for CIPSO on Linux (again) In-Reply-To: <435EA137.7080803@hp.com> References: <435E7939.2070007@hp.com> <20051025184032.GY5856@shell0.pdx.osdl.net> <435E82EF.90606@hp.com> <20051025200203.GT7991@shell0.pdx.osdl.net> <435EA137.7080803@hp.com> Message-ID: <20051025224606.GB5856@shell0.pdx.osdl.net> * Paul Moore (paul.moore at hp.com) wrote: > Chris Wright wrote: > >I guess that's my point. Using ipsec...so use ipsec ;-) > > Yes, but the nice thing is that if you don't want or need IPsec you > don't have to use IPsec. If you need both data and label integrity as > well as data confidentiality and you don't need interoperability with > non-Linux hosts than Trent's IPsec extensions are ideal; for everything > else CIPSO may present an attractive option to customers. > > Not everyone needs hmacs and encryption to ensure data integrity and > confidentiality. Sure, if you have dedicated private network, or similar guarantees. IPSec is reasonably flexible (perhaps to a fault), and key exchange aside, I believe you can make a pretty insecure SA using NULL algorithms, etc. But that doesn't address interoperability w/ existing CIPSO based systems. > >Yes, I saw that with post_create hook. But didn't look too far to see > >that the socket label copied to every fragment, since LSM post_create by > >itself is not enough. Nor did I see where you protect from setsockopt > >to turn it off? I think the whole idea is harder to show secure, than > >using ipsec approach. I also didn't see how you handle raw sockets. > > > > Can you point to where setting an IP option in the socket does not cause > it to be set for every packet (I'm not trying to be atognistic here, I'm > just trying to find something I missed - I don't have the extensive > Linux stack background that some of you do)? I believe options handling (on sending) is already coded to cope with fragments, but that's with standard options. Actually, looking at the code, I believe it'd just be in the definition of the option (i.e. |IPOPT_COPY should do it). On receipt, I was assuming you'd have to add something to check each fragment before adding to reassembly queue. This is a check in a hot path that is bound to be expensive (and not one that netdev will take lightly at all). Once you get to sock_rcv_skb you've lost the options on each fragment packet, because reassembly processing has already reassembled all the data. > As far as using > setsockopt() to turn it off, why not simply use SELinux to restrict the > application from setting socket options? I would think on a system > running CIPSO would want to disallow applications from setting IP level > options anyway. Also, and this should answer your raw socket question > as well, the netfilter module would still be able to catch all the > packets heading out of the system to ensure they were labeled with the > acceptable range. Yes, using existing hooks can mediate these, I just wanted to point it out, since your text didn't. > >>Regarding encapsulation, encapsulation within what? Another IPv4 > >>header? An IPv6 header? > > > >Either, really. But I was thinking of GRE and IP-in-IP type. Point is, > >I think doing it right (meaning can't undermine the protection) is what > >requires more invasive hooks. > > All right, your correct in that it probably shouldn't matter but is > exporting the label to the outermost protocol really what you want to > do? For instance, CIPSO isn't really even defined for IPv6 (although it > appears some OSs do support it, I haven't seen a packet dump yet but I > suspect it is through destination options). You certainly want the innermost since that's where the actual payload is. But, you probably want both to make sure the outer tunnel can't be used to bypass checks. I don't know the right answer, but it's another area where you may have to hook. > >This is the only compelling reasoning, but it's not technical, and I > >think the technical issues outweigh here. The problem is the performance > >hit is felt too far and wide. This is processing that has to happen on > >every outbound and inbound packet. Inbound is certainly helped since > >we have security_sock_rcv_skb. > > Interoperability I think is a *very* compelling reason, heck, it is the > only reason I bothered to spend some time and see if I could come up > with a way to maybe make CIPSO work. Understood. Problem is, it's impossible to sell this as 'non-niche' technology. And if it hurts mainline, it will simply not fly. > I think the IPsec extensions offer > a lot, and it would be great if some day the other big MLS OSs supported > the IPsec extensions. However, that is not the case today and I think > we need a option that can work alongside existing MLS solutions. I see the need, I just haven't been convinced that this can be done in a way that will be acceptable upstream. At which point, it's a custom hack, and you should do whatever you like ;-) > Regarding performance, I just don't get your argument. Currently the > only alternative we have is IPsec and I am pretty confident that a CIPSO > implementation can be made to have less overhead than IPsec, even using > just AH and a fast hash algorithm. No, that's not what I mean. CIPSO vs. IPSec is irrelevant. It's current mainline (no packet labelling) vs. mainline w/ packet labelling. If adding packet labelling has a negative performance impact on users who don't require (or even remotely care about) packet labelling, it's a non-starter. Inbound packet processing is highly optimized, and it's easy to make large regressions with small changes. > >>Also, please keep in mind that my CIPSO proposal and Trent's IPsec > >>approach are not mutually exclusive. Both can co-exist in a running > >>kernel. > > > >*nod* > > At least we can agree on something ;) Heh ;-) thanks, -chris From chrisw at osdl.org Tue Oct 25 23:04:50 2005 From: chrisw at osdl.org (Chris Wright) Date: Tue, 25 Oct 2005 16:04:50 -0700 Subject: [redhat-lspp] [RFC] A Proposal for CIPSO on Linux (again) In-Reply-To: <435EA600.7090300@hp.com> References: <435E7939.2070007@hp.com> <1130267260.21689.171.camel@ea.austin.ibm.com> <435E85E0.80107@hp.com> <1130273000.21689.236.camel@ea.austin.ibm.com> <435EA600.7090300@hp.com> Message-ID: <20051025230450.GC5856@shell0.pdx.osdl.net> * Paul Moore (paul.moore at hp.com) wrote: > However, just because we don't think CIPSO is a good solution doesn't > mean people aren't using it. Once again, some people do not need wire > based encryption or hmacs. Right, similaraly, just because a relatively niche area uses it doesn't mean mainline Linux has to support it. The problem is it's almost guaranteed to hurt packet processing performance of many for the gain a few. > I answered this in one of my responses to Chris so I'll refer you to my > to him. However, regarding as to how I would get my patch upstream well > I would probably start by sending my proposal to Dave Miller at first > and let him know that I am trying to fix some of his objections to > James' original patch and see what he had to say. I would assume there > would be some back and forth and hopefully he would be open to seeing a > new patch ... I figure just because one implementation dies a nasty > death doesn't mean we have to give up - does it? I think it is worth > trying again. I'd talk to James first. Not only did he do the original work and can do a much better job at describing the issues than I can, but he's also a network maintainer. Also, your proposal is not likely to go anywhere unless it's a) posted to a list (not just DaveM or James), b) accompanied with code, c) accompanied with all the details about why it will absolutely _not_ hurt mainline networking performance, d) some difficult arguing over why this needs to go in as well as the IPSec based work from Trent, e) goat sacrifice... ;-) Put it this way...it's been literally years (including original CIPSO work) to get labelled networking merged upstream, and it's still a work in progress (albeit IPSec based one is very likely to be accepted based on the continual refinements). thanks, -chris From ltcgcw at us.ibm.com Wed Oct 26 00:11:58 2005 From: ltcgcw at us.ibm.com (George Wilson) Date: Tue, 25 Oct 2005 19:11:58 -0500 Subject: [redhat-lspp] LSPP/RBACPP requirements v.004 Message-ID: <1130285518.21689.256.camel@ea.austin.ibm.com> I have the next iteration of the requirements list pulled from my mySQL task DB. There are additional tables, one of which maps back to CC requirements, that aren't joined. I am happy to provide a dump of the DB. If Russell sets up a wiki, perhaps it can live there and we can all manage the status of our own tasks. Please note that "Owner" means that person will be on point to ensure the item is completed, not necessarily to perform the task itself. I have another table for contributors to a item. Steve and I have our names beside many items. I used us as default owners. Ownership needs to be assigned to the appropriate person as necessary. Also, the DB already needs some updates. I'll take care of that tomorrow after the meeting. Percentage complete is only an estimate. This iteration does incorporate Steve's comments. In case you're wondering, this is v.004 because I considered Steve's v.003. Please kick this list around. -- George Wilson IBM Linux Technology Center -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: lspptasks004.ps Type: application/postscript Size: 252427 bytes Desc: not available URL: -------------- next part -------------- 01 Audit record augmentation Description: Augment audit records with additional LSPP & RBACPP attributes: subj and obj labels; roles, host identity, event type, and access types where available. Implementation: IBM posted a patch on linux-audit. Status: Patch posted to audit list by IBM; issues being addressed. Upstream: Red Hat, lkml Owner: Kirkland, Dustin Org: IBM 02 Audit of additional events Description: Add additional instrumentation to kernel and userspace, particularly for user data import/export; catchall for issues not covered elsewhere. May include new audit record types for: rlimit violations, sub, obj, anomolies, responses. Implementation: Red Hat and IBM have expressed interest on mailing lists. Status: Ongoing Upstream: Red Hat, lkml Owner: Grubb, Steve Org: Red Hat 03 Audit of network events Description: Add hooks to IPsec implicit packet labeling. Needs to include audit by network address. Implementation: Should mostly be covered by existing AVC audit records. IBM likely to be interested in this in conjunction with labeled network packets. May need to document that network configuration changes require reboot (per @sec). DHCP should be disallowed. Status: Trent Jaeger has base IPsec packet labeling posted on netdev. 2 patches pending. Need getsockopt() of packet labels. Upstream: netdev, lkml Owner: Zhang, Catherine Org: IBM 04 Audit of print events Description: Instrument CUPS. Implementation: HP posted a patch and discussed extensively on this list. Status: Patch needs to go upstream to CUPS list. Upstream: CUPS mailing list Owner: Maple, James Org: TCS 05 Audit of other import/export events Description: Device allocation; force labeling of devices. Implementation: Open Status: Open Upstream: Individual dev mailing lists Owner: Grubb, Steve Org: Red Hat 06 Audit of user and role modifications Description: Instrument tools that modify users and roles in flat file implementation. Includes passwd. Utilities upon which this depends covered in separate task. Implementation: Open Status: Open Upstream: Open; shadow-utils? Owner: Grubb, Steve Org: Red Hat 07 Audit instrumentation of trusted programs, including SELinux tools Description: Add hooks to trusted programs. At the moment, looks like only newrole needs to be instrumented--others are audited by kernel. CUPS client may also be a candidate. Implementation: Instrument newrole for audit, make it suid, and drop capabilities other than audit append. Status: Determine if newrole is only utility that requires instrumentation. Upstream: SELinux list, kernel community Owner: Grubb, Steve Org: Red Hat 08 Audit-fs completion Description: Completion of auditfs patch. Implementation: Implementation in progress by IBM. Status: IBM posted patch and discussed linux-audit; intends to complete work. Upstream: fsdevel, lkml Owner: Griffis, Amy Org: HP 09 Audit filtering in kernel or daemon with additional LSPP & RBACPP attributes--Selective Audit Description: Add kernel or daemon audit filtering to CAPP audit. Solution must filter/suppress records based on all available LSPP & RBACPP attributes: obj and subj labels, object identity, role, hostname, event type, and access type. Implementation: Red Hat has expressed interest on linux-audit. Status: Red Hat creating new design. Upstream: Red Hat, lkml Owner: Grubb, Steve Org: Red Hat 10 Audit browse, sort, search (augrep) with additional LSPP & RBACPP attributes--Audit Selection Description: Create command line browse utility. Must include all avaliable LSPP & RBACPP attributes: obj and subj labels, object identity, role, hostname, event type, and access type. Note there is no X-window System in certified configuration. Implementation: Red Hat has expressed interest on mailing lists. Needs API and binary record format support. Status: ASCII ausearch w/sub and obj labels implemented; API proposed on list; binary record format being discussed. Upstream: Red Hat Owner: Grubb, Steve Org: Red Hat 11 DAC policy and function Description: Existing DAC mechanisms should cover; ensure all objects are covered and ensure owner, perm bits, ACLs are appropriate. Implementation: Open Status: Needs to be analyzed to ensure complete coverage. Upstream: Certification RPM only? Owner: Wilson, George Org: IBM 12 MLS policy and function Description: SELinux MLS function and base MLS policy provide foundation; require a real MLS policy that correctly deals with trusted processes, overrides, restrictions on import/export, VFS polyinstantiation; plus extensive testing. Implementation: NSA, TCS, Tresys, Red Hat, and others have posted patches. Status: Need "real" MLS policy; does anybody have one? Also, IBM has been having to write MLS policy for testcases. Upstream: NSA selinux mailing list. Owner: Hanson, Chad Org: TCS 13 IPsec labeled packets: Base patch Description: Indirect packet labeling based on mapping IPsec SAs to SELinux security contexts; AH-only with physical network security reduces/eliminates FIPS crypto cert requirements. Implementation: Trent Jaeger / IBM posted patch to netdev. They plan to continue working this item. Status: Base patch on netdev; ipsec-tools and getsockopt() for label need to be posted to maintainer lists once base patch is accepted into kernel; also requires testing. Upstream: netdev, lkml Owner: Jaeger, Trent Org: PSU 14 Labeled print Description: TCS patch posted to redhat-lspp + mods by HP and others; also need print tests. Implementation: TCS posted patch. It has generated extensive comments. HP posted an audit instrumentation patch for it. Status: Patch looks promising; more comments to incorporate; requires testing. Upstream: CUPS mailing list Owner: Hanson, Chad Org: TCS 15 VFS polyinstantiation Description: Namespaces unshare syscall patch and PAM exploitation of it. Implementation: NSA posted polyinstantiation patch. Red Hat been working on namespaces extensively. IBM has posted unshare syscall patch and PAM integration patches. Status: Patches need to be accepted; comments slow in arriving. Upstream: lkml, pam-list Owner: Desai, Janak Org: IBM 16 Device allocation Description: Device allocation patch posted by TCS + enhancements, and/or forced relabeling upon device insertion; requires testing. Functions: authorization, synchronization, device node context assignment, eject/close. Implementation: TCS posted framework patch. HP posted policy for it. Status: Agreed that we need a device allocator. Release of additional work pending license from TCS. Upstream: Open Owner: Hanson, Chad Org: TCS 17 Test and restrict file archivers Description: star already maintains xattrs. Do we want label support on any other archivers? Need to restrict all the others to an administrator. Enhancements to other archivers exceed LSPP reqs. Implementation: Open; IBM is looking at adding xattr support to zip/unzip. Status: star works but needs comprehensive testing. Need to investigate need for other archivers. Need to investigate restrictions via policy. Upstream: archiver maintainers for modifications; selinux list for policy Owner: Velarde, Debora Org: IBM 18 Device labeling via udev Description: udev patch would force relabeling upon hotplug/mount. No hotplug events shall label devices. It can only make sure they are unlabeled. (L/FDP_ETC, FDP_ITC) Implementation: Nolan @ Red Hat seemed to think this was a big deal. Fundamentally breaks way folks designing udev intended udev to be used. Need udev maintainer buy-in. Status: Requires more analysis. Upstream: udev maintainer? Unclear this can be upstreamed. Owner: Grubb, Steve Org: Red Hat 19 Label translation Description: Translation of sensitivity labels into human-readable form. Implementation: TCS posted patch to selinux list. Others have commented extensively. Red Hat appears to have the most up-to-date implementation. Status: TCS posted patch to selinux list. Red Hat has posted a patch as well. Upstream: Open Owner: Hanson, Chad Org: TCS 20 Mail Description: User mail required for admin mail only, probably only cron. Possible solutions: multi-level MTA, admin-only MTA, direct procmail invocation; direct delivery by cron into poly'd directories. Complete solution may be interesting but is not a requirement. Implementation: IBM is looking at this approach. Russell Coker recently became interested in adding labels to messages. Status: Requires analysis to determine if approach is satisfactory. Upstream: Certification RPM only? Owner: Coker, Russell Org: Red Hat 21 Multilevel xinetd Description: Patch xinetd to obtain label from inbound connections and spawn child daemons with correct context. WIll have to be documented as trusted program. Implementation: TCS has posted a patch. Reauires IPsec labeled network packets conext getsockopt(). Status: Simple patch exists; some debate over range bracketing. Upstream: Steve Grubb, xinetd list Owner: Hanson, Chad Org: TCS 22 Multilevel sshd Description: Patch sshd to spawn child processes with correct context. Implementation: This may be possible by simply patching PAM module. Status: Requires more analysis; would we favor this approach in lieu of multilevel xinetd? Upstream: openssh-unix-dev Owner: Zhang, Catherine Org: IBM 23 Multilevel cron Description: TCS posted polyinstantiation-aware Vixie cron; TCS approach useful, but useful only for MLS labels and dependent on TCS polyinstantiation mechanism. Comments on redhat-lspp suggest extending cron/crontab protocol to support security context. Implementation: TCS posted the patch; IBM is working to integrate with namespaces-based polyinstantiation. Status: High-level approach on extending cron/crontab protocol being worked on by IBM. Upstream: Vixie cron; unclear this will be upstreamable. Owner: Desai, Janak Org: IBM 24 Multilevel at Description: Base at work on multilevel cron. Implementation: Open; IBM and TCS are likely interested in this as they have been working on cron. Status: Requires investigation. Upstream: at maintainer Owner: Desai, Janak Org: IBM 25 Multilevel tmpwatch Description: Patch tmpwatch to handle polyinstantiation. Implementation: Open Status: Requires investigation. Upstream: tmpwatch maintainer Owner: Desai, Janak Org: IBM 26 Multilevel slocate Description: Consider removing from package list. Otherwise, patch slocate to handle polyinstantiation. Implementation: Concensus at last discussion was to remove this package from the evaluated configuration. Status: Requires investigation; Russell Coker mentioned having to patch slocate for his open root play machines. Upstream: Red Hat Certification RPM,slocate Owner: Desai, Janak Org: IBM 27 Revocation of user and object attributes Description: Killall with user and context matching and wrapper script to lock account and kill all user processes. Similar approach can be taken with fuser. Implementation: IBM has psmisc patch to be posted. Needs to use loginuid and document regex caveats as well. Status: IBM has patch to killall and revocation script; to be posted on selinux list and redhat-lspp. Upstream: psmisc sf project Owner: Wilson, George Org: IBM 28 Useful role definitions Description: Define a useful set of roles in the MLS policy. The admin roles should be separated, and a super admin role composed from them. Overrides also need to be tied to roles. Consider including a crypto admin role. Implementation: Red Hat added role separation to MLS policy with input from TCS. Status: Role separation already done in the existing MLS policy. Expound on this work and document. Upstream: selinux list Owner: Wilson, George Org: IBM 29 Management of users and roles in flat file Description: Create command line tools to manage and audit users and roles in flat file separated from base MLS policy. Actions need to be audited, which is covered in a separate task. Implementation: Red Hat has been working on flat file user and roles implementation. Status: These tools need to be created and instrumented with audit hooks. Upstream: shadow-utils? Owner: Grubb, Steve Org: Red Hat 30 Self tests Description: Define a subset of LTP tests that can be run periodically by an administrator or cron job that demonstrates correct operation DAC and MAC policies, and verifies integrity of configuration files, including SELinux policy. Tests shall produce audit records. Implementation: Open; IBM has some ideas for this. Likely permission and label checks via script, binary integrity validation via rpm -V, and LTP subset. Status: NSA SELinux tests are incorporated into LTP. Select a subset of these, verify critical DAC permissions, and check integrity of critical configuration files. Also, NSA adding integrity verification and version tagging of SELinux policy. Upstream: Certification RPM only? Owner: Wilson, George Org: IBM 31 I&A Description: All these requirements are similar to CAPP. Augment tests to account for sensitivity labels. Implementation: IBM plans to test this. Status: This is test work to verify that I&A functionality. IBM plans to perform this work. Upstream: LTP? Owner: Desai, Janak Org: IBM 32 Test Description: Create testcases and incorporate into LTP. Implementation: Respective task owners should create unit and functional tests. Status: Ongoing Upstream: LTP Owner: Wilson, Kris Org: IBM 33 Documentation Description: Create documentation for each task. Implementation: Respective task owners should create low-level design documentation, manpages, and structured comments. Status: Ongoing Upstream: Respective upstream maintainers Owner: Wilson, George Org: IBM 34 Ensure all named objects are covered by DAC & MAC Description: Objects shall include: files, named pipes (fifo), sockets, devices, shared memory, message queue, semaphores. New object: kernel keys - would need man pages, structured comments, & test cases. Implementation: IBM should ensure complete coverage. Status: No development work; ensure coverage in ST. Upstream: Red Hat Certification RPM Owner: Wilson, George Org: IBM 35 Provide minimal number of MAC levels and categories Description: There shall at least 16 levels of hierachial labels and 64 compartments (L/FDP_IFF.2.7). However, we should have 256 compartments per customer requirement. Implementation: IBM should ensure complete coverage. Status: No development work; ensure coverage in ST; RH has customer reqs beyond LSPP. Upstream: SELinux mailing list Owner: Wilson, George Org: IBM 36 Audit record unique session/terminal ID Description: Events shall contain unique session identifier and/or terminal. Implementation: Could be and ID a la loginuid; don't want to add a new one; only required when available; incomplete coverage; add to audit records where available. Status: Expand coverage of terminal ID. Upstream: lkml, linux-audit Owner: Grubb, Steve Org: Red Hat 37 Analyze removing DBUS Description: DBUS must be either documented and tested, restricted, or removed. Ideally it will be removed from the ST. Implementation: Remove dbus and see what breaks; discuss with Russell. Status: Open and high priority Upstream: Red Hat Certification RPM Owner: Grubb, Steve Org: Red Hat 39 Restrict kernel keyring access Description: There needs to be a way to restrict the use of the kernel keyring to the authorized administrator. Implementation: The restrictions should be defined in the MAC policy, and DAC, too, if possible. Status: Open Upstream: Red Hat Certification RPM Owner: Wilson, George Org: IBM 40 Standard LSPP configuration Description: Create standard LSPP configuration and rules to be shared among contributors. This may be incorporated into Configuration Guide. Implementation: Write scripts and documentation for LSPP & RBACPP configuration. Status: Russell Coker looking at setting up wiki for collbaoration on documentation. Upstream: Red Hat Certification RPM, README for selinux-list, Configuration Guide Owner: Grubb, Steve Org: Red Hat 41 Audit of SELinux booleans Description: Changing policy booleans is auditable event. Implementation: SELinux needs to generate audit records when policy booleans are changed. Unclear to what extent this is already covered. Status: Requires analysis Upstream: SELinux list Owner: Grubb, Steve Org: Red Hat 42 Audit of service discontinuity Description: Service discontinuity is auditable event. Implementation: Ensure that all service discontinuities are audited--bootup, shutdown, SELinux enable, SELinux disable. Status: Should already be covered; need to ensure that is the case. Upstream: SELinux list, linux-audit Owner: Grubb, Steve Org: Red Hat 43 Audit record subject labels for userspace records Description: When user space message is relayed, add a subject message to same event. Implementation: The kernel needs to add the subject label for audit records generated in userspace because the caller cannot be trusted. Status: Steve Grubb already planning to add. Upstream: SELinux list, linux-audit Owner: Grubb, Steve Org: Red Hat 44 Fail to secure state Description: When role data base is offline, corrupt, or unaccessable, the system shall preserve a secure state. Implementation: SELinux denies everything by default. So, if the SS, DB, or policy is unavailable, the system should come to a stop. Status: Should already be covered by SELinux; ensure that it is. Upstream: SELinux list Owner: Walsh, Dan Org: Red Hat 45 Maintenance mode for secure recovery Description: RBAC stipulates that after a failure or service discontinuity, the machine shall enter a maintenance mode whereby the machine can be restored to a secure state. Maybe config param for rc.sysinit. Implementation: Perhaps need to add a new init state for secure recovery. Status: Requires analysis; may not require a new init state. Upstream: Red Hat certification RPM Owner: Walsh, Dan Org: Red Hat 47 Utility to list SELinux roles? Description: User shall have the ability to see list of authorized Roles. This does not appear to be a strict requirement looking at RBACPP FIA_ATD.1. Implementation: This is not required by would be nice to have. Is there already a way to do this? If not, need a utility for a user to list roles that he/she can take on. Status: Nice to have. Determine if this should be removed from requirements list. Upstream: SELinux list, Red Hat certification RPM Owner: Wilson, George Org: IBM 48 User role modification? Description: User shall have the ability to change to any authorized Roles. Unclear that this is required by reading RBACPP FMT_SMR.2; TSF needs to associate, admins need to control. Implementation: Mechanism already exists for TSF to associate users and roles, and for admin roles to control them. Users must be restricted. Status: Determine if this should be removed. For Klaus: When a user changes roles, is that an auditable event? We should amend this item to include auditability of role change based on Klaus' feelings. Otherwise strike from list as it's covered by newrole. Upstream: Red Hat certification RPM Owner: Wilson, George Org: IBM 49 MLS enablement of userspace Description: All utilities that display contexts shall be updated to display levels and catagories. They shall display the translated name. Implementation: Ensure all userspace utilities display levels and catagoreies correcly. This should already be done. Unclear that they should always display xlated names. Status: Determine where xlations should be displayed. Should alredy be done. Should be determined by ongoing test and use. Upstream: SELinux list, Red Hat certification RPM Owner: Grubb, Steve Org: Red Hat 50 Utility to compute closure of sub access to objs? Description: Given a file, the Admin shall be able to determine who can access it. Request from military customers. Implementation: Requires analysis of DAC permissions and SELinux policy. Status: Nice to have. Determine if should be removed from requirements list. Upstream: Red Hat certification RPM Owner: Grubb, Steve Org: Red Hat 51 IPsec labeled packets: Userspace ipsec-tools patch Description: This is the userspace ipsec-tools patch that accompanies the kernel base patch. Implementation: Joy Latten and Trent Jaeger modified ipsec-tools to handle syntax modifications required by kernel base patch. Status: Joy has forward ported the patch. It will be posted to the ipsec-tools list when the base patch is upstream. Upstream: ipsec-tools Owner: Latten, Joy Org: IBM 53 IPsec labeled packets: Analyzers Description: Tcpdump and ethereal need to understand IPsec labels. This is not an LSPP/RBACPP requirement. Implementation: Augment tcpdump and ethereal. This would be AH-only, I presume, unless the sniffers can decrypt ESP. Status: Open; Likely a nice to have item. Upstream: Tcpdump and ethereal maintainers Owner: Grubb, Steve Org: Red Hat 50 rows in set From jmorris at redhat.com Wed Oct 26 04:05:01 2005 From: jmorris at redhat.com (James Morris) Date: Wed, 26 Oct 2005 00:05:01 -0400 (EDT) Subject: [redhat-lspp] [RFC] A Proposal for CIPSO on Linux (again) In-Reply-To: <435E7939.2070007@hp.com> References: <435E7939.2070007@hp.com> Message-ID: On Tue, 25 Oct 2005, Paul Moore wrote: > ip_options.c (to make it CIPSO aware) and a new netfilter module. I believe > all of the access decisions and packet labeling can be done using the existing > LSM hooks. I would greatly appreciate any feedback you can offer. I suspect this can be done without impacting too negatively on mainline. As Chris suggested, you'll need to verify the label for each incoming fragment. You could also consider not supporting IP fragmentation when labeling is enabled (dropping or rejecting them via netfilter and ensuring the system is configured correctly). Fragmentation is really only used for NFS over UDP, and NFS over TCP is the way to go anyway. I'm not sure why you'd need a separate netfilter module to check packets. Just check them from within SELinux, which itself can use the Netfilter API. Technical issues aside, I think you can make an argument to support CIPSO options in mainline for the same reasons there are legacy filesystems in the kernel. Whether CIPSO is a transitional technology or not is not really our concern here. You could almost say the same thing about MLS itself. Mainline inclusion of CIPSO code can probably be justified with: - the fact that people are using it at all - providing interoperability with other production OSs - an implementation which doesn't negatively impact on non-users - isolating the code (e.g. making it configurable, and easy for maintainers to deal with) - commitment to maintaining the code from existing maintainers or someone they trust (including yourself of course) -- James Morris From jmorris at redhat.com Wed Oct 26 04:16:36 2005 From: jmorris at redhat.com (James Morris) Date: Wed, 26 Oct 2005 00:16:36 -0400 (EDT) Subject: [redhat-lspp] [RFC] A Proposal for CIPSO on Linux (again) In-Reply-To: <435E82EF.90606@hp.com> References: <435E7939.2070007@hp.com> <20051025184032.GY5856@shell0.pdx.osdl.net> <435E82EF.90606@hp.com> Message-ID: On Tue, 25 Oct 2005, Paul Moore wrote: > are running multi-level networks using CIPSO and so far the feedback we have > received from them is that implicit packet labeling using non-standard > extensions to IKE/IPsec is not really an option. As a side issue, I would hope that once implemented, we can get IPSec labeling on the IETF standards track. - James -- James Morris From paul.moore at hp.com Wed Oct 26 13:13:56 2005 From: paul.moore at hp.com (Paul Moore) Date: Wed, 26 Oct 2005 09:13:56 -0400 Subject: [redhat-lspp] [RFC] A Proposal for CIPSO on Linux (again) In-Reply-To: References: <435E7939.2070007@hp.com> <20051025184032.GY5856@shell0.pdx.osdl.net> <435E82EF.90606@hp.com> Message-ID: <435F8114.2040707@hp.com> James Morris wrote: > On Tue, 25 Oct 2005, Paul Moore wrote: > > >>are running multi-level networks using CIPSO and so far the feedback we have >>received from them is that implicit packet labeling using non-standard >>extensions to IKE/IPsec is not really an option. > > As a side issue, I would hope that once implemented, we can get IPSec > labeling on the IETF standards track. > It would really be nice to see some form of labeled networking reach RFC status. If and when that happens it should help remove the need for CIPSO and all the controversy it seems to cause around here ;) -- . paul moore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . paul.moore at hp.com hewlett packard . (603) 884-5056 linux security From paul.moore at hp.com Wed Oct 26 13:21:07 2005 From: paul.moore at hp.com (Paul Moore) Date: Wed, 26 Oct 2005 09:21:07 -0400 Subject: [redhat-lspp] [RFC] A Proposal for CIPSO on Linux (again) In-Reply-To: References: <435E7939.2070007@hp.com> Message-ID: <435F82C3.5000904@hp.com> James Morris wrote: > On Tue, 25 Oct 2005, Paul Moore wrote: >>ip_options.c (to make it CIPSO aware) and a new netfilter module. I believe >>all of the access decisions and packet labeling can be done using the existing >>LSM hooks. I would greatly appreciate any feedback you can offer. > > I suspect this can be done without impacting too negatively on mainline. > > As Chris suggested, you'll need to verify the label for each incoming > fragment. You could also consider not supporting IP fragmentation when > labeling is enabled (dropping or rejecting them via netfilter and ensuring > the system is configured correctly). Fragmentation is really only used > for NFS over UDP, and NFS over TCP is the way to go anyway. Thanks for the feedback. I tend to think the impact on the mainline kernel should be rather minimal as well, at least that was/is one of my goals. > I'm not sure why you'd need a separate netfilter module to check packets. > Just check them from within SELinux, which itself can use the Netfilter > API. I'm probably just using a bad choice of words to describe what I mean; what I mean by 'a new netfilter module' was a new function that plugged into the netfilter stack. I think this is what you are getting at? > Technical issues aside, I think you can make an argument to support CIPSO > options in mainline for the same reasons there are legacy filesystems in > the kernel. Whether CIPSO is a transitional technology or not is not > really our concern here. You could almost say the same thing about MLS > itself. > > Mainline inclusion of CIPSO code can probably be justified with: > - the fact that people are using it at all > - providing interoperability with other production OSs > - an implementation which doesn't negatively impact on non-users > - isolating the code (e.g. making it configurable, and easy for > maintainers to deal with) > - commitment to maintaining the code from existing maintainers or someone > they trust (including yourself of course) > Thanks, that's good to hear. -- . paul moore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . paul.moore at hp.com hewlett packard . (603) 884-5056 linux security From paul.moore at hp.com Wed Oct 26 13:29:48 2005 From: paul.moore at hp.com (Paul Moore) Date: Wed, 26 Oct 2005 09:29:48 -0400 Subject: [redhat-lspp] [RFC] A Proposal for CIPSO on Linux (again) In-Reply-To: <20051025224606.GB5856@shell0.pdx.osdl.net> References: <435E7939.2070007@hp.com> <20051025184032.GY5856@shell0.pdx.osdl.net> <435E82EF.90606@hp.com> <20051025200203.GT7991@shell0.pdx.osdl.net> <435EA137.7080803@hp.com> <20051025224606.GB5856@shell0.pdx.osdl.net> Message-ID: <435F84CC.10107@hp.com> Chris Wright wrote: >>As far as using >>setsockopt() to turn it off, why not simply use SELinux to restrict the >>application from setting socket options? I would think on a system >>running CIPSO would want to disallow applications from setting IP level >>options anyway. Also, and this should answer your raw socket question >>as well, the netfilter module would still be able to catch all the >>packets heading out of the system to ensure they were labeled with the >>acceptable range. > > > Yes, using existing hooks can mediate these, I just wanted to point it > out, since your text didn't. > Thanks, that's a good point - I should have mentioned it - I'll update my notes. >>>This is the only compelling reasoning, but it's not technical, and I >>>think the technical issues outweigh here. The problem is the performance >>>hit is felt too far and wide. This is processing that has to happen on >>>every outbound and inbound packet. Inbound is certainly helped since >>>we have security_sock_rcv_skb. >> >>Interoperability I think is a *very* compelling reason, heck, it is the >>only reason I bothered to spend some time and see if I could come up >>with a way to maybe make CIPSO work. > > Understood. Problem is, it's impossible to sell this as 'non-niche' > technology. And if it hurts mainline, it will simply not fly. > Oh, I wouldn't even try to sell this as anything but a niche protocol. I *think* I can cobble up a CIPSO implementation using the ideas here and not impact mainline too badly ... but hey, I've been wrong before and I'm pretty certain I'll be wrong again - yet I still keep trying. I'm not asking you to implement the design Chris, I was just asking for feedback; which I got, thank you. -- . paul moore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . paul.moore at hp.com hewlett packard . (603) 884-5056 linux security From William.Roe at gd-ais.com Wed Oct 26 14:30:37 2005 From: William.Roe at gd-ais.com (Roe, William H.) Date: Wed, 26 Oct 2005 10:30:37 -0400 Subject: [redhat-lspp] [RFC] A Proposal for CIPSO on Linux (again) Message-ID: There is a long history of labeled protocols besides IPSEC. Please take note of RIPSO. Here is a quick list: Having an operating system that supports labels is excellent, but what if you want to interconnect more than one computer? Standard TCP/IP protocols are not security label aware. This means that additional "label-aware" protocols are necessary for communication between MAC supported operating systems. Revised IP Security Option (RIPSO) is an internet protocol based on RFC 1108 and can be located at http://www.faqs.org/rfc/rfc1108.html. The RIPSO protocol addresses two internet protocol options: * DoD Basic Security: Classification Level and protection authority flags. * DoD Extended Security: Additional security information. Commercial Internet Protocol Security Option (CIPSO) is used to specify security labels that are passes in the IP packet options field. This can cause some network hardware to fail and should be tested thoroughly prior to deployment. CISPO information can be found at http://www.ietf.org. Security Attribute Token Mapping Protocol (SATMP) is based on the Trusted Systems Information eXchange for Restricted Environments standard). SATMP information can be found at http://www.sun.com. Security Attribute Mapping Protocol (SAMP) is a derivative passed security attributes on the network protocol stack like SATMP, but uses different header structures and is based upon the CIPSO protocol. SAMP information can be found at http://www.sun.com. Trusted Solaris Protocol (TSOL) is derived from the SAMP protocol using similar header structures, but passes security attributes in binary form and thus does not require token mapping. TSOL information can be found at http://www.sun.com. William Roe, CISSP, M.S. IA General Dynamics, IMS-EDIS-AIS Technical Engineering Matrix Manager Sr. Lead Software Engineer 410/859-2076 office 443/220-8910 blackberry william.roe at gd-ais.com -----Original Message----- From: redhat-lspp-bounces at redhat.com [mailto:redhat-lspp-bounces at redhat.com] On Behalf Of Paul Moore Sent: Wednesday, October 26, 2005 9:14 AM To: James Morris Cc: Chris Wright; redhat-lspp at redhat.com Subject: Re: [redhat-lspp] [RFC] A Proposal for CIPSO on Linux (again) James Morris wrote: > On Tue, 25 Oct 2005, Paul Moore wrote: > > >>are running multi-level networks using CIPSO and so far the feedback >>we have received from them is that implicit packet labeling using >>non-standard extensions to IKE/IPsec is not really an option. > > As a side issue, I would hope that once implemented, we can get IPSec > labeling on the IETF standards track. > It would really be nice to see some form of labeled networking reach RFC status. If and when that happens it should help remove the need for CIPSO and all the controversy it seems to cause around here ;) -- . paul moore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . paul.moore at hp.com hewlett packard . (603) 884-5056 linux security -- redhat-lspp mailing list redhat-lspp at redhat.com https://www.redhat.com/mailman/listinfo/redhat-lspp From rob.myers at gtri.gatech.edu Wed Oct 26 14:34:43 2005 From: rob.myers at gtri.gatech.edu (Rob Myers) Date: Wed, 26 Oct 2005 10:34:43 -0400 Subject: [redhat-lspp] [RFC] A Proposal for CIPSO on Linux (again) In-Reply-To: <435EA35C.8020402@hp.com> References: <435E7939.2070007@hp.com> <1130267260.21689.171.camel@ea.austin.ibm.com> <435E85E0.80107@hp.com> <20051025204834.GA5856@shell0.pdx.osdl.net> <435EA35C.8020402@hp.com> Message-ID: <1130337283.8431.11.camel@rXm-581b.stl.gtri.gatech.edu> On Tue, 2005-10-25 at 17:27 -0400, Paul Moore wrote: > Chris Wright wrote: > > * Paul Moore (paul.moore at hp.com) wrote: > >>As far as putting the MLS Linux system behind a trusted router/guard, > >>this would require the guard to understand the IPsec/IKE extensions or > > > > Yes, that's the idea. It's a way to do the migration that Joe > > mentioned, and hopefully not burden mainline with transitional > > technology. > > But who is going to build such a guard? I doubt Sun will, they already > have a working labeled network solution (CIPSO) why should they bother > playing well with Linux? perhaps you could work with the opensolaris community to build such a guard? rob. From William.Roe at gd-ais.com Wed Oct 26 14:43:06 2005 From: William.Roe at gd-ais.com (Roe, William H.) Date: Wed, 26 Oct 2005 10:43:06 -0400 Subject: [redhat-lspp] [RFC] A Proposal for CIPSO on Linux (again) Message-ID: If CIPSO, RIPSO, or TSOL protocols are deployed on a classified network the interconnections between networks are encrypted with type-I encryptors. Subsequently, the packet including the encapsulated header is not subject to modification. It is only within the trusted enclave that the danger becomes real, and that is by a trusted insider which is another problem altogether. The policies should prevent the trusted insider from running ethereal or other unauthorized apps such as hping. I see the issue as a charter problem. The project documents published back in 1999 state specifically that IPSEC will be used and offers no other alternatives. Please correct me if I am wrong about this. William Roe, CISSP, M.S. IA General Dynamics, IMS-EDIS-AIS Technical Engineering Matrix Manager Sr. Lead Software Engineer 410/859-2076 office 443/220-8910 blackberry william.roe at gd-ais.com Confidentiality Note: This e-mail is intended only for the person or entity to which it is addressed, and may contain information that is privileged, confidential, or otherwise protected from disclosure. Dissemination, distribution, or copying of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this e-mail in error, please notify the sender by reply e-mail, phone, or fax, and destroy the original message and all copies. Thank you. -----Original Message----- From: redhat-lspp-bounces at redhat.com [mailto:redhat-lspp-bounces at redhat.com] On Behalf Of Roe, William H. Sent: Wednesday, October 26, 2005 10:31 AM To: Paul Moore; James Morris Cc: Chris Wright; redhat-lspp at redhat.com Subject: RE: [redhat-lspp] [RFC] A Proposal for CIPSO on Linux (again) There is a long history of labeled protocols besides IPSEC. Please take note of RIPSO. Here is a quick list: Having an operating system that supports labels is excellent, but what if you want to interconnect more than one computer? Standard TCP/IP protocols are not security label aware. This means that additional "label-aware" protocols are necessary for communication between MAC supported operating systems. Revised IP Security Option (RIPSO) is an internet protocol based on RFC 1108 and can be located at http://www.faqs.org/rfc/rfc1108.html. The RIPSO protocol addresses two internet protocol options: * DoD Basic Security: Classification Level and protection authority flags. * DoD Extended Security: Additional security information. Commercial Internet Protocol Security Option (CIPSO) is used to specify security labels that are passes in the IP packet options field. This can cause some network hardware to fail and should be tested thoroughly prior to deployment. CISPO information can be found at http://www.ietf.org. Security Attribute Token Mapping Protocol (SATMP) is based on the Trusted Systems Information eXchange for Restricted Environments standard). SATMP information can be found at http://www.sun.com. Security Attribute Mapping Protocol (SAMP) is a derivative passed security attributes on the network protocol stack like SATMP, but uses different header structures and is based upon the CIPSO protocol. SAMP information can be found at http://www.sun.com. Trusted Solaris Protocol (TSOL) is derived from the SAMP protocol using similar header structures, but passes security attributes in binary form and thus does not require token mapping. TSOL information can be found at http://www.sun.com. William Roe, CISSP, M.S. IA General Dynamics, IMS-EDIS-AIS Technical Engineering Matrix Manager Sr. Lead Software Engineer 410/859-2076 office 443/220-8910 blackberry william.roe at gd-ais.com -----Original Message----- From: redhat-lspp-bounces at redhat.com [mailto:redhat-lspp-bounces at redhat.com] On Behalf Of Paul Moore Sent: Wednesday, October 26, 2005 9:14 AM To: James Morris Cc: Chris Wright; redhat-lspp at redhat.com Subject: Re: [redhat-lspp] [RFC] A Proposal for CIPSO on Linux (again) James Morris wrote: > On Tue, 25 Oct 2005, Paul Moore wrote: > > >>are running multi-level networks using CIPSO and so far the feedback >>we have received from them is that implicit packet labeling using >>non-standard extensions to IKE/IPsec is not really an option. > > As a side issue, I would hope that once implemented, we can get IPSec > labeling on the IETF standards track. > It would really be nice to see some form of labeled networking reach RFC status. If and when that happens it should help remove the need for CIPSO and all the controversy it seems to cause around here ;) -- . paul moore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . paul.moore at hp.com hewlett packard . (603) 884-5056 linux security -- redhat-lspp mailing list redhat-lspp at redhat.com https://www.redhat.com/mailman/listinfo/redhat-lspp -- redhat-lspp mailing list redhat-lspp at redhat.com https://www.redhat.com/mailman/listinfo/redhat-lspp From jmorris at redhat.com Wed Oct 26 15:13:23 2005 From: jmorris at redhat.com (James Morris) Date: Wed, 26 Oct 2005 11:13:23 -0400 (EDT) Subject: [redhat-lspp] [RFC] A Proposal for CIPSO on Linux (again) In-Reply-To: <435F82C3.5000904@hp.com> References: <435E7939.2070007@hp.com> <435F82C3.5000904@hp.com> Message-ID: On Wed, 26 Oct 2005, Paul Moore wrote: > I'm probably just using a bad choice of words to describe what I mean; what I > mean by 'a new netfilter module' was a new function that plugged into the > netfilter stack. I think this is what you are getting at? Yes -- SELinux does that already for outgoing packets. - James -- James Morris From czhang.us at gmail.com Wed Oct 26 15:25:13 2005 From: czhang.us at gmail.com (Catherine Zhang) Date: Wed, 26 Oct 2005 11:25:13 -0400 Subject: [redhat-lspp] UDP secpeer design document Message-ID: Hi, everyone, Below is a brief design document on implementing the UDP secpeer functionality. Comments are appreciated! regards, Catherine IBM Research ---------------- 1. Purpose The goal is to provide the API for an application to retrieve the security context of the peer for the UDP protocol. We would like to achieve this without labelling individual skbuff. 2. Background Unlike TCP, UDP is connectionless. This requires a somewhat different API to retrieve the peer security context. With TCP, the peer security context stays the same throughout the connection, thus it can be retrieved at any time between when the connection is extablished and when it is torn down. With UDP, each read/write can have different peer and thus the security context might change every time. As a result the retrieval must be done BEFORE the packet is read. 3. Design We decide to use the same getsockopt() call for retrieving security context. The function however has different meaning under UDP and TCP. Under UDP, it retrieves the peer security context of the NEXT packet, whereas under TCP, it retrieves the peer security context of the CURRENT connection. An example server application for UDP should look like this: getsockopt(sockfd, SOL_SOCKET, SO_PEEK_PEERSEC, outbuf, &optlen); switch (outbuf) { case "normal_u:...": // fork a normal_u process; case "special_u:...": // fork a special_u process; ... } There is yet another complication for the case of UDP. When the getsockopt is called, there might not be any data available. Thus we are faced with 2 design choices for getsockopt when there is no data: a) return an ENODATA error, and require the application to poll the socket (using select() call) and issue the getsockopt call only when there is data available. b) block the call until there is data. Choice a) is easier to implement but it shifts the programming burden to the application writer. Choice b) makes the application writer's job easier, but it turns getsockopt into a blocking call, which might not be acceptable (can't think of a good reason now). 4. Implementation We plan to get the security context from the sec_path pointer which is contained in the skbuff. 5. Issues Scatter and gather was considered a possible issue. It turns out to be fine. According to the UDP definition, each read should return only one packet. This rule should apply to readv/writev. Since one packet can only have one label, this should not be a problem. From William.Roe at gd-ais.com Wed Oct 26 13:16:35 2005 From: William.Roe at gd-ais.com (Roe, William H.) Date: Wed, 26 Oct 2005 09:16:35 -0400 Subject: FW: Fwd: Re: [redhat-lspp] [RFC] A Proposal for CIPSO on Linux(again) Message-ID: If CIPSO is deployed on a classified network the interconnections between networks are encrypted with type-I encryptors. Subsequently, the packet including the encapsulated header is not subject to modification. It is only within the trusted enclave that the danger becomes real, and that is by a trusted insider which is another problem altogether. The policies should prevent the trusted insider from running ethereal or other unauthorized apps. I see the issue as a charter problem. The project documents published back in 1999 state specifically that IPSEC will be used and no other alternatives. William Roe, CISSP, M.S. IA General Dynamics, IMS-EDIS-AIS Technical Engineering Matrix Manager Sr. Lead Software Engineer 410/859-2076 office 443/220-8910 blackberry william.roe at gd-ais.com -----Original Message----- From: redhat-lspp-bounces at redhat.com [mailto:redhat-lspp-bounces at redhat.com] On Behalf Of schaufler-ca.com - Casey Schaufler Sent: Tuesday, October 25, 2005 3:49 PM To: redhat-lspp at redhat.com Subject: Fwd: Fwd: Re: [redhat-lspp] [RFC] A Proposal for CIPSO on Linux(again) --- Chris Wright wrote: > What?s the point? CIPSO is meaningless w/out packet header integrity And it's not a hamburger without the pickle. The reality is that CIPSO systems have been deployed since the last 1980's. I understand that there are people out there who can't grasp the notion of a security feature that does not use encryption. That notion killed TSIG. There are numerous environments where CIPSO is just fine. > which requires encryption, which looks what Trent is working on now. Yeah, whatever. > Also do you handle fragments, and encapsulation? You don't. You don't need to if you do it right. -- redhat-lspp mailing list redhat-lspp at redhat.com https://www.redhat.com/mailman/listinfo/redhat-lspp From serue at us.ibm.com Wed Oct 26 15:57:52 2005 From: serue at us.ibm.com (Serge Hallyn) Date: Wed, 26 Oct 2005 10:57:52 -0500 Subject: [redhat-lspp] UDP secpeer design document In-Reply-To: References: Message-ID: <20051026155752.GA9251@sergelap.austin.ibm.com> Quoting Catherine Zhang (czhang.us at gmail.com): > An example server application for UDP should look like this: > > getsockopt(sockfd, SOL_SOCKET, SO_PEEK_PEERSEC, outbuf, &optlen); > switch (outbuf) { > case "normal_u:...": // fork a normal_u process; > case "special_u:...": // fork a special_u process; > ... > } > > There is yet another complication for the case of UDP. When the > getsockopt is called, there might not be any data available. Thus we > are faced with 2 design choices for getsockopt when there is no data: > > a) return an ENODATA error, and require the application to poll > the socket (using select() call) and issue the getsockopt call > only when there is data available. > > b) block the call until there is data. > > Choice a) is easier to implement but it shifts the programming burden > to the application writer. Choice b) makes the application writer's > job easier, but it turns getsockopt into a blocking call, which might > not be acceptable (can't think of a good reason now). I think (a) is the reasonable approach. Anyone who wants (b) can write a library call which does both select and getsockopt, leaving only potential thread locking issues for the application to deal with... thanks, -serge From chrisw at osdl.org Wed Oct 26 18:18:29 2005 From: chrisw at osdl.org (Chris Wright) Date: Wed, 26 Oct 2005 11:18:29 -0700 Subject: [redhat-lspp] [RFC] A Proposal for CIPSO on Linux (again) In-Reply-To: <435F84CC.10107@hp.com> References: <435E7939.2070007@hp.com> <20051025184032.GY5856@shell0.pdx.osdl.net> <435E82EF.90606@hp.com> <20051025200203.GT7991@shell0.pdx.osdl.net> <435EA137.7080803@hp.com> <20051025224606.GB5856@shell0.pdx.osdl.net> <435F84CC.10107@hp.com> Message-ID: <20051026181829.GH5856@shell0.pdx.osdl.net> * Paul Moore (paul.moore at hp.com) wrote: > Oh, I wouldn't even try to sell this as anything but a niche protocol. > I *think* I can cobble up a CIPSO implementation using the ideas here > and not impact mainline too badly ... but hey, I've been wrong before > and I'm pretty certain I'll be wrong again - yet I still keep trying. > I'm not asking you to implement the design Chris, I was just asking for > feedback; which I got, thank you. Ah it's fine, I didn't have the impression you were asking me (or anyone else) to implement. Just debating the potential issues with CIPSO implementation. I think trying it out and measuring the impact is a fine idea. thanks, -chris From dvelarde at us.ibm.com Wed Oct 26 22:30:12 2005 From: dvelarde at us.ibm.com (Debora Velarde) Date: Wed, 26 Oct 2005 17:30:12 -0500 Subject: [redhat-lspp] LSPP Development Telecon 10/26/2005 Minutes Message-ID: ------------------------ LSPP Meeting 10/26/2005 ------------------------ Known Attendees: Matt Anderson (HP) Mounir Bsabies (IBM) Janak Desai (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) Joy Latten (IBM) Paul Moore (HP) James Morris (HP) Emily Ratliff (IBM) Stephen Smalley (NSA) Debora Velarde (IBM) Dan Walsh (Red Hat) George Wilson (IBM) Kris Wilson (IBM) Venkat Yekkirala (TCS) Catherine Zhang (IBM) Tentative Agenda: IPsec labels VFS polyinstantiation Audit Package list File archivers Print DBUS Device allocation Tasks and assignments Documentation Test ----- CIPSO ----- - Paul posted CIPSO proposal on list - Perhaps too negative of a response initially on the list. - James Morris looking at it and giving suggestions. - Gives hope that it could make it to the kernel. - Paul has an up and running implementation. - Possibility of RH carrying it if it doesn't make upstream? Goal needs to be to get it upstream. ------------ IPsec labels ------------ - Trent submitted patch to utilize the socket sid as part of the elements your going to use to look up entry in the flow cache Now items in the flow cache are already authorized for the sid System is now deterministic w/ respect to the flow cache - Herbert happy about that - Performance implication of calculating sid multiple times - Trent removed multiple calculations on execution path and resent patch - Catherine coming up with proposal of getting labels off of packets - Catherine sent out design doc yesterday and updated one this morning - UDP compared to TCP: need to make the call before you retrieve the UDP message Make call first, get peak security peer Then retrieve message Then fork off children with diff security context to cover those messages - getsockopt() implementation options: 1. Venkat's implementation no data error returned app has to constantly pull on the network socket when data is avail then issue the getsockopt() call 2. block getsockopt() call until there is data - Catherine deciding which way to go - soliciting comments from people, opinions? please post comments/opinions to the list or bring up now - ACTION: Catherine to post to the lspp list ----------------- polyinstantiation ----------------- - Janak still waiting to hear from Chris Wright - Chris wanted to double check that clone could not be used and unshared is needed - Janak did make changes Chris asked for - Janak will post updated patch on LKML when he hears back from Chris Wright - The patch Janak posted to lspp list is the latest version - Includes unsharing of namespace and VM but nothing else - unsharing of signal handlers can be added later - Janak will ping Chris Wright again today ----- audit ----- Userspace - Steve Grubb released new audit version 1.0.8 finishes development of audit report fixes all known bugs so far - started moving all trusted applications to new logging format showing up in rawhide tomorrow shadow-utils longer - newrole will also add new audit logging to newrole Steve had a code review this week a couple things that need to be cleaned up George wants to get coverity run on it kernel -David built a kernel need it to go to a yum repo so all could pick it up looking for an announcement audit-fs - Amy submitted first patch - Included in test kernel David built - should help Dustin with some of the features he wanted to add - Amy and Dustin had discussion about the rest of the work - They have idea for design of the rest of work simpler and would be more likely to be accepted upstream. -------------------- Task and assignments -------------------- - Need to revisit package list Steve Grubb wanted to match tasks to packages not sure if we want to do this now Steve thinks that's the only way to really have a checklist George has package list that was derived from the CAPP package list Russell not on call to ask about setting up the wiki - George broke up network tasks into more tasks. - George will make another round of updates and hopefully can get with Russell to put it on the wiki - Steve asked Linda if she has taken a look at the list. - When she looks if she sees anything please chime in. - Linda noted a couple items that look stale, such as printing - Please send George a note with updates - default owners - hard to tell if person is default owner or if someone is really working on it - Would be good to note if the default owner is looking for help - George has another workers table but states this is a good suggestion -------------- file archivers -------------- - Debbie posted patch to zip & unzip - No comments posted yet - Not strictly lspp requirement but star format not so popular - Dan going to look at it and have Red Hat zip maintainer look at it too - Please send any feedback to debbie ----- print ----- - Matt doing conversion from compile time to runtime options - Matt playing with it on MLS proper - Trying to ramp up some of the testing to have better coverage - Need to audit some of the admin side actions - Checking that auditing covers more of what is required for LSPP ---------- CIPSO cont ---------- - James joined the call missed the previous discussion about CIPSO - James posted a response last night on the list - Mainline inclusion could be possible, if keep the code isolated make semantics clear for existing maintainers - If Paul wants to give it a go then its probably worth trying - Due to Paul's other commitments, progress on this is probably going to be a little slow at the beginning - Paul can email James w/ other questions and CC the list - Chad (or James?) can point to places he knows with trusted solaris info - CIPSO might have a chance and is useful - Doesn't have to be part of the lspp Can be an update somewhere down the track post lspp ---- DBUS ---- - Removing or restricting it? - Need to make a policy to restrict - It has the needed infrastructure - But we don't want to have to document it so we would like to cut it out of the evaluation - Since it does have the controls, is security relevant - What uses DBUS? HAL, some communication of bind, DHCP daemon - Dan spoke with bind and DHCP maintainers and they said they should still work - Probably easiest thing is to shut it down and see if system still works - Chad(?): good policy on netlink sockets? Beyond documenting it, don't think we've done anything special for it yet George: if you have an issue please do bring it up, even if it's in an email ---------------- device allocator ---------------- - Dan trying to round up all packages that are completely MLS specific - ACTION : Chad to make sourceforge project - Dan not the upstream maintainer - rpm package: mls-utils - Question: Should the sourceforge project be more than the dev allocator? No because will end up being the maintainer for all of them ----- Other ----- - Tim is freed up - Debora is going to free up in a week or so - Is there somewhere that we could help? - Steve sent Tim a list with 11 suggestions (most quick, 1 longer) longer one: Be able to track child processes through the audit rules not strictly required for lspp - A task that is high priority: LSPP standard audit configuration depends on: 1. Security Target 2. Having the filesystem auditing in place Need to start flushing out Standard audit config files Rather see that at the beginning of the project than the end of it - Kris has tried configuring Fedora core system to use MLS policy but had some problems with that - We need more documentation - Would like everyone that writes code to document it - Ideally would also create new testcases for new code - Particularly if it can be incorporated in LTP - Putting it in LTP, means that our test teams could be running them - Are there testcases for audit in LTP? No, nothing from the certification is public yet - Push to get reference policy up in next week Dan wants to put out a kit that people will try w/in the next week - Stephen Smalley wants reference policy thinks its the right path going forward - 2 weeks slip of fedora, might help - Red Hat lost conference room - Talk about add'l changes need to labelled networking patch - Mention of folks looking at MLS implications of IPSEC labelled networking and thought there needed to be additions to patch to play well with MLS - Venkat is looking at that - Finding out each possible context If have 1 machine talking to another and have 10,000 possible permutations or say any communication in range is allowed Instead of defining them all ahead of time (scalability problem) From dvelarde at us.ibm.com Wed Oct 26 23:05:12 2005 From: dvelarde at us.ibm.com (Debora Velarde) Date: Wed, 26 Oct 2005 18:05:12 -0500 Subject: [redhat-lspp] LSPP Development Telecon 10/26/2005 Minutes In-Reply-To: Message-ID: > James Morris (HP) Correction: James Morris (Red Hat) Apologies, debora From dwalsh at redhat.com Thu Oct 27 03:59:05 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 26 Oct 2005 23:59:05 -0400 Subject: [redhat-lspp] [PATCH] Changes to dev_allocator-0.4 In-Reply-To: <43564B6A.1090500@hp.com> References: <43564B6A.1090500@hp.com> Message-ID: <43605089.1020503@redhat.com> Missing devalloc_status and devalloc_close dev_allocator.o: In function `main': dev_allocator.c:(.text+0x261): undefined reference to `devalloc_status' dev_allocator.c:(.text+0x2d0): undefined reference to `devalloc_close' collect2: ld returned 1 exit status -- From rcoker at redhat.com Thu Oct 27 11:45:14 2005 From: rcoker at redhat.com (Russell Coker) Date: Thu, 27 Oct 2005 21:45:14 +1000 Subject: [redhat-lspp] [RFC] A Proposal for CIPSO on Linux (again) In-Reply-To: <1130337283.8431.11.camel@rXm-581b.stl.gtri.gatech.edu> References: <435E7939.2070007@hp.com> <1130267260.21689.171.camel@ea.austin.ibm.com> <435E85E0.80107@hp.com> <20051025204834.GA5856@shell0.pdx.osdl.net> <435EA35C.8020402@hp.com> <1130337283.8431.11.camel@rXm-581b.stl.gtri.gatech.edu> Message-ID: <1130413514.10524.39.camel@aeon> On Wed, 2005-10-26 at 10:34 -0400, Rob Myers wrote: > > But who is going to build such a guard? I doubt Sun will, they already > > have a working labeled network solution (CIPSO) why should they bother > > playing well with Linux? > > perhaps you could work with the opensolaris community to build such a > guard? It's often difficult to get open source communities to help with large security related projects. I had Debian production servers running SE Linux in 2002 with all necessary code in Debian packages. Now the code in question has only just been accepted in to Debian packages (apart from coreutils which is still in progress), support for SE Linux in the Debian installer has not been discussed yet. In that time period we have had SE Linux fully supported in three Fedora Core releases and one Red Hat Enterprise Linux release with FC5 and RHEL5 on the way. Getting the OpenSolaris community to work on such things is unlikely to happen. Getting one person from the OpenSolaris community to work on it is quite feasible, but one person could be found from other open source areas (such as the existing SE Linux community). From paul.moore at hp.com Thu Oct 27 12:46:09 2005 From: paul.moore at hp.com (Paul Moore) Date: Thu, 27 Oct 2005 08:46:09 -0400 Subject: [redhat-lspp] LSPP Development Telecon 10/26/2005 Minutes In-Reply-To: References: Message-ID: <4360CC11.3030708@hp.com> Debora Velarde wrote: > ------------------------ > LSPP Meeting 10/26/2005 > ------------------------ > > ----- > CIPSO > ----- > - Paul posted CIPSO proposal on list > - Perhaps too negative of a response initially on the list. > - James Morris looking at it and giving suggestions. > - Gives hope that it could make it to the kernel. > - Paul has an up and running implementation. That last bullet point should probably read "Paul hopes to have an up and running implementation" ;) I don't have any code yet, I was floating the proposal to the list to see if others thought it would be worthwhile. After the concall it sounds like it is so I will be starting work on the code soon. > - Possibility of RH carrying it if it doesn't make upstream? > Goal needs to be to get it upstream. -- . paul moore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . paul.moore at hp.com hewlett packard . (603) 884-5056 linux security From paul.moore at hp.com Thu Oct 27 14:54:51 2005 From: paul.moore at hp.com (Paul Moore) Date: Thu, 27 Oct 2005 10:54:51 -0400 Subject: [redhat-lspp] [PATCH] Changes to dev_allocator-0.4 In-Reply-To: <43605089.1020503@redhat.com> References: <43564B6A.1090500@hp.com> <43605089.1020503@redhat.com> Message-ID: <4360EA3B.4000200@hp.com> Daniel J Walsh wrote: > Missing devalloc_status and devalloc_close > > dev_allocator.o: In function `main': > dev_allocator.c:(.text+0x261): undefined reference to `devalloc_status' > dev_allocator.c:(.text+0x2d0): undefined reference to `devalloc_close' > collect2: ld returned 1 exit status > My apologies, I left two files out of the patch I sent (forgot to do an svn add, so the svn diff never picked them up - oops). Apply the attached patch on top of the one I already sent. -- . paul moore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . paul.moore at hp.com hewlett packard . (603) 884-5056 linux security -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch-10272005.txt URL: From dwalsh at redhat.com Thu Oct 27 21:08:14 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 27 Oct 2005 17:08:14 -0400 Subject: [redhat-lspp] mlsutils package is available on my people site. Message-ID: <436141BE.3020808@redhat.com> ftp://people.redhat.com/dwalsh/SELinux/Fedora -- From chanson at TrustedCS.com Fri Oct 28 18:38:48 2005 From: chanson at TrustedCS.com (Chad Hanson) Date: Fri, 28 Oct 2005 14:38:48 -0400 Subject: [redhat-lspp] CIPSO Info Message-ID: <36282A1733C57546BE392885C0618592D96F66@chaos.tcs.tcs-sec.com> Per the request on the telecon, I have gathered a few links on CIPSO. http://www.sun.com/software/solaris/trustedsolaris/ts_tech_faq/faqs/CIPSO_sz .xml http://docs.sun.com/app/docs/doc/805-8024/6j7hv2egv?a=view http://neutrino.inin.mx/cgi-bin/infosrch.cgi?cmd=getdoc&coll=0650&db=man&fna me=7%20trusted_networking -Chad