From mra at hp.com Wed Nov 1 00:47:19 2006 From: mra at hp.com (Matt Anderson) Date: Tue, 31 Oct 2006 19:47:19 -0500 Subject: [redhat-lspp] Re: New MLS constraint? In-Reply-To: <1161020854.26428.32.camel@sgc> References: <4533B60E.8010802@hp.com> <1161020854.26428.32.camel@sgc> Message-ID: <4547EE97.5040101@hp.com> Christopher J. PeBenito wrote: > We could add another 'or' on the above constraint: > > or ( (t2 == mlsfilewrite_in_range) and (l1 dom l2) and (h1 domby h2) ) > > I believe that would be the constraint you were looking for. I don't > like the name of that attribute, but I couldn't come up with a better > one off the top of my head. :) > Attached is a patch which I've tested against selinux-policy-2.4.2-1 that implements this additional constraint. The name is still a bit forced, but it works. -matt -------------- next part -------------- A non-text attachment was scrubbed... Name: writeinrange.patch Type: text/x-patch Size: 1943 bytes Desc: not available URL: From sds at tycho.nsa.gov Wed Nov 1 12:36:43 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 01 Nov 2006 07:36:43 -0500 Subject: [redhat-lspp] Re: [PATCH 2/3] Re: MLS enforcing PTYs, sshd, and newrole In-Reply-To: <1162319582.23631.1.camel@code.and.org> References: <20061012153701.75777.qmail@web36603.mail.mud.yahoo.com> <45377BF0.6010403@redhat.com> <1161264613.14632.120.camel@moss-spartans.epoch.ncsc.mil> <1161620097.667.10.camel@code.and.org> <1161722236.667.20.camel@code.and.org> <1161776892.3987.193.camel@moss-spartans.epoch.ncsc.mil> <1161778937.3987.218.camel@moss-spartans.epoch.ncsc.mil> <1161784251.667.28.camel@code.and.org> <1161784759.3987.295.camel@moss-spartans.epoch.ncsc.mil> <1161803724.29689.57.camel@code.and.org> <1161804290.3987.388.camel@moss-spartans.epoch.ncsc.mil> <1161970810.29689.88.camel@code.and.org> <1161974293.1306.167.camel@moss-spartans.epoch.ncsc.mil> <1162238632.31104.11.camel@code.and.org> <1162239394.31104.13.camel@code.and.org> <1162304610.32614.24.camel@moss-spartans.epoch.ncsc.mil> <1162304681.32614.26.camel@moss-spartans.epoch.ncsc.mil> <1162306839.31104.23.camel@code.and.org> <1162307495.32614.47.camel@moss-spartans.epoch.ncsc.mil> <1162310652.31104.46.camel@code.and.org> <1162311675.32614.81.camel@moss-spartans.epoch.ncsc.mil> <1162319582.23631.1.camel@code.and.org> Message-ID: <1162384603.32614.163.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2006-10-31 at 13:33 -0500, James Antill wrote: > On Tue, 2006-10-31 at 11:21 -0500, Stephen Smalley wrote: > > > No. The ability to make the security call is controlled by the > > compute_av permission on the security class, and isn't based on the > > individual contexts passed as arguments. That would be: > > allow $1 security_t:security compute_av; > > which has an interface: > > selinux_compute_access_vector($1) > > which is already in authlogin.if. No change required for allowing the > > call to happen. > > > > What you are instead trying to do is to define the _result_ of that > > compute_av call based on its arguments, not whether it can be made by > > login. So the TE rule would go into userdomain.if and be of the form: > > allow $1 self:context ; > > Ok, I think I have it now. Both patches are at (with the renamed > permission): > > http://people.redhat.com/jantill/pam-config_role/upstream/ They look sane to me. Please post them in separate messages, preferably inline, and cc Chris PeBenito on the policy patch. -- Stephen Smalley National Security Agency From cpebenito at tresys.com Wed Nov 1 15:41:00 2006 From: cpebenito at tresys.com (Christopher J. PeBenito) Date: Wed, 01 Nov 2006 10:41:00 -0500 Subject: [redhat-lspp] Re: New MLS constraint? In-Reply-To: <4547EE97.5040101@hp.com> References: <4533B60E.8010802@hp.com> <1161020854.26428.32.camel@sgc> <4547EE97.5040101@hp.com> Message-ID: <1162395661.31675.165.camel@sgc> On Tue, 2006-10-31 at 19:47 -0500, Matt Anderson wrote: > Christopher J. PeBenito wrote: > > We could add another 'or' on the above constraint: > > > > or ( (t2 == mlsfilewrite_in_range) and (l1 dom l2) and (h1 domby h2) ) > > > > I believe that would be the constraint you were looking for. I don't > > like the name of that attribute, but I couldn't come up with a better > > one off the top of my head. :) > > > > Attached is a patch which I've tested against selinux-policy-2.4.2-1 > that implements this additional constraint. The name is still a bit > forced, but it works. Merged. Moved the printer_device_t line to devices. -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 From paul.moore at hp.com Fri Nov 3 16:00:11 2006 From: paul.moore at hp.com (Paul Moore) Date: Fri, 03 Nov 2006 11:00:11 -0500 Subject: [redhat-lspp] NetLabel LTP test results Message-ID: <454B678B.5050700@hp.com> Yesterday I ran some of the LTP network tests with the goal of checking for any regressions caused by NetLabel. In summary, there were no regressions seen with NetLabel present but not enabled; however, there were some failures with NetLabel enabled but they were expected (details below). Test Setup: o Local Machine - HP rx2600 (ia64) - Fedora Rawhide with the lspp.54 kernel - Targeted policy in permissive mode o Remote Machine - HP dc7100 (x86) - Fedora Rawhide with the lspp.54 kernel - MLS policy in permissive mode NetLabel present but not enabled (default lspp.54 configuration): o network_commands - All 7 tests PASS o nfs - All 8 tests PASS o tcp_cmds - All 18 tests PASS NetLabel present and enabled: *** NetLabel configuration START *** # netlabelctl cipsov4 add pass doi:1 tags:1 # netlabelctl map del default # netlabelctl map add default protocol:cipsov4,1 # netlabelctl unlbl accept off *** NetLabel configuartion END *** *** NOTES *** - Several of the LTP network tests had to be modified to honor the $LTP_RSH variable so that ssh could be used in place of the "r" commands which did not work well with CIPSO options (see below). - In kernel daemons such as NFS are a known problem for SELinux/LSM since these "daemons" bypass many of the LSM hooks that are required for proper MAC controls. This is a known problem and has been discussed on the mailing lists from time to time. *** NOTES *** o network_commands - All 7 tests PASS o nfs - Only 2 tests PASS (nfslock01, nfsstat01) - Remaining 6 tests FAIL (nfs01, nfs02, nfs03, nfs04, nfsstress, nfsx-linux) + Failures are expected due to nfs being handled by the in-kernel daemon which bypasses many of the LSM hooks responsibile for NetLabel labeling, allowing unlabeled NetLabel traffic allowed these tests to PASS. + Unlabeled NetLabel traffic is enabled by: netlabelctl unlbl accept on o tcp_cmds - 12 tests PASS (arp, echo, finger, ftp, netstat, perf_lan, rsh, sendfile, tcpdump, telnet, iptables, dhcpd) - 6 tests FAIL (host, ping, rcp, rdist, rlogin, rwho) + The host test failed because my DNS server does not understand CIPSO. + The ping test failed because it was trying to manipulate the IP options (it was using the record route option), normal pings work just fine with NetLabel enabled. + The "r" commands failed because the server tries to remove all the options from a socket, including the CIPSO option. -- paul moore linux security @ hp From ltcgcw at us.ibm.com Fri Nov 3 23:48:48 2006 From: ltcgcw at us.ibm.com (George C. Wilson) Date: Fri, 3 Nov 2006 17:48:48 -0600 Subject: [redhat-lspp] [Reminder] Open LSPP Development Telecon Mon., Nov. 6 Message-ID: <20061103234848.GA32629@us.ibm.com> IBM hosts a telecon every Monday at 21:00 UTC 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 mra at hp.com Mon Nov 6 17:36:24 2006 From: mra at hp.com (Matt Anderson) Date: Mon, 06 Nov 2006 12:36:24 -0500 Subject: [redhat-lspp] Policy for aide Message-ID: <454F7298.9070306@hp.com> Here is an initial attempt at an aide policy. So far I've only been testing it on strict-mls so if you are using the Tresys reference policy Makefile.example you'll need to use TYPE=strict-mls as an option to build it. This policy assumes that /var/lib/aide/ exists and is aide_db_t:SysHigh. It does not allow aide_t to read shadow_t, even though it is common to have aide check the shadow files, since there is an assert in the policy against types reading shadow_t. Aide can complete its scan without being able to read shadow files with only a little complaining. The testing of this policy has focused on using James Antill's aide.conf and his patched version of aide which is SELinux aware. http://people.redhat.com/jantill/aide/ -matt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: aide.fc URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: aide.if URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: aide.te URL: From efleury at br.ibm.com Mon Nov 6 18:35:21 2006 From: efleury at br.ibm.com (Eduardo Madeira Fleury) Date: Mon, 6 Nov 2006 16:35:21 -0200 Subject: [redhat-lspp] CUPS w/ Matt's config in RHEL5 not printing? Message-ID: <200611061635.21400.efleury@br.ibm.com> Hey all, I'm trying to setup a USB printer in RHEL5 Server 10/27 refresh using the configuration steps described at http://free.linux.hp.com/~mra/docs/ but I'm not being able to. I did the following: # lpadmin -p Printer1 -E -v usb://Lexmark/T630 -m postscript.ppd.gz # lpadmin -p Printer2 -E -v usb:/dev/usb/lp0 -m postscript.ppd.gz Where /dev/usb/lp0 is the device the Lexmark is connected to. Ok, then I try to print in Permissive: # lpr -P Printer1 mytestpage.ps Nothing happens # lpstat-p printer Printer1 is idle. enabled since Mon 06 Nov 2006 08:29:03 AM CST /usr/lib/cups/filter/pstops failed (...) # lpr -P Printer2 mytestpage.ps Nothing happens # lpstat -p (...) printer Printer2 is idle. enabled since Mon 06 Nov 2006 08:30:52 AM CST /usr/lib/cups/filter/pstops failed In Enforcing same happens to Printer1. For Printer2, lpr returns "lpr: SELinux prohibits access to the printer" what should be because the /dev URI is deprecated, anyway Printer1 doesn't work either so that's not the problem. >From the other threads seems there's still some development going on, is that right? Is this a (known) bug? Thanks, -- Eduardo M. Fleury IBM Linux Technology Center Brazil Mobile: +55-19-81224410 email/sametime: efleury at br.ibm.com From mra at hp.com Mon Nov 6 19:09:38 2006 From: mra at hp.com (Matt Anderson) Date: Mon, 06 Nov 2006 14:09:38 -0500 Subject: [redhat-lspp] CUPS w/ Matt's config in RHEL5 not printing? In-Reply-To: <200611061635.21400.efleury@br.ibm.com> References: <200611061635.21400.efleury@br.ibm.com> Message-ID: <454F8872.8060600@hp.com> Eduardo Madeira Fleury wrote: > Hey all, > > I'm trying to setup a USB printer in RHEL5 Server 10/27 refresh using the > configuration steps described at http://free.linux.hp.com/~mra/docs/ but I'm > not being able to. > > I did the following: > > # lpadmin -p Printer1 -E -v usb://Lexmark/T630 -m postscript.ppd.gz > # lpadmin -p Printer2 -E -v usb:/dev/usb/lp0 -m postscript.ppd.gz > > Where /dev/usb/lp0 is the device the Lexmark is connected to. > > Ok, then I try to print in Permissive: > > # lpr -P Printer1 mytestpage.ps > Nothing happens > > # lpstat-p > printer Printer1 is idle. enabled since Mon 06 Nov 2006 08:29:03 AM CST > /usr/lib/cups/filter/pstops failed > (...) > > # lpr -P Printer2 mytestpage.ps > Nothing happens > > # lpstat -p > (...) > printer Printer2 is idle. enabled since Mon 06 Nov 2006 08:30:52 AM CST > /usr/lib/cups/filter/pstops failed > > In Enforcing same happens to Printer1. For Printer2, lpr returns > "lpr: SELinux prohibits access to the printer" what should be because the /dev > URI is deprecated, anyway Printer1 doesn't work either so that's not the > problem. > >>From the other threads seems there's still some development going on, is that > right? Is this a (known) bug? > > Thanks, You should still be getting the SELinux deny on the printer since the needed constraint wasn't in the policy. I got an update on my bugzilla and the constraint will be included starting with the selinux policy 2.4.3-1 rpm. As for the usb://Lexmark/T630 URI printers without /dev/ in their URI are not checked for file system permissions before the job is sent. Your admin guide should specify that printers MUST be created with the /dev/usb/lp* style URI. >From the error you are seeing it sounds like the pstops filter is having trouble with your postscript document. If you revert the config files to their defaults do you still see that problem? -matt From efleury at br.ibm.com Mon Nov 6 19:38:25 2006 From: efleury at br.ibm.com (Eduardo Madeira Fleury) Date: Mon, 6 Nov 2006 17:38:25 -0200 Subject: Fwd: Re: [redhat-lspp] CUPS w/ Matt's config in RHEL5 not printing? Message-ID: <200611061738.25583.efleury@br.ibm.com> Forgot to reply-all. ---------- Forwarded Message ---------- Subject: Re: [redhat-lspp] CUPS w/ Matt's config in RHEL5 not printing? Date: Monday 06 November 2006 17:37 From: Eduardo Madeira Fleury To: Matt Anderson On Monday 06 November 2006 17:09, you wrote: > You should still be getting the SELinux deny on the printer since the > needed constraint wasn't in the policy. I got an update on my bugzilla > and the constraint will be included starting with the selinux policy > 2.4.3-1 rpm. Thanks, so that's a matter of waiting for another refresh. > As for the usb://Lexmark/T630 URI printers without /dev/ in their URI > are not checked for file system permissions before the job is sent. > Your admin guide should specify that printers MUST be created with the > /dev/usb/lp* style URI. Yes, I remember that discussion, actually I used the Manufacturer/Model URI only to try to isolate the problem. > From the error you are seeing it sounds like the pstops filter is having > trouble with your postscript document. If you revert the config files > to their defaults do you still see that problem? No, if I revert the config files the printer works fine. Actually, reversing only mime.convs and mime.types is enough for it to work, and banner pages are printed fine also. > -matt Thanks, -- Eduardo M. Fleury IBM Linux Technology Center Brazil Mobile: +55-19-81224410 email/sametime: efleury at br.ibm.com ------------------------------------------------------- -- Eduardo M. Fleury IBM Linux Technology Center Brazil Mobile: +55-19-81224410 email/sametime: efleury at br.ibm.com From loulwas at us.ibm.com Tue Nov 7 00:33:59 2006 From: loulwas at us.ibm.com (Loulwa Salem) Date: Mon, 06 Nov 2006 18:33:59 -0600 Subject: [redhat-lspp] LSPP Development Telecon 11/06/2006 Minutes Message-ID: <454FD477.7020306@us.ibm.com> 11/06/2006 lspp Meeting Minutes: =============================== Attendees Robin Redden (IBM) - RR Lawrence Wilson (IBM) - LW George Wilson (IBM) - GW Kris Wilson (IBM) - KEW Loulwa Salem (IBM) - LS Michael Thompson (IBM) - MT Joy Latten (IBM) - JL Kylene Hall (IBM) - KH Irina Boverman (Red Hat) - IB Steve Grubb (Red Hat) - SG Dan Walsh (Red Hat) - DW James Antill (Red Hat) - JA Matt Anderson (HP) - MA Klaus Weidner (Atsec) - KW Darrel Goeddel (TCS) - DG Chad Hanson (TCS) - CH Tentative Agenda: GW: I hacked on self test and I have something to put on the list, it is still incomplete but you can use it to test what you have now. Thanks for the policy Matt, I didn't try it yet. MA: It should be good, just make sure you put that option in there, the one I sent you in the email. JA: the aide policy seems to include a massive list of types at the end. Is that all the types it looks at? MA: yes JA: my problem is if someone installs lspp and have aide to look at it, then it needs to be added KW: it would make more sense to give aide a read override MA: perhaps that works GW: yeah, might make the most sense Kernel update ------------- GW: any one wants to talk about current kernel. I had a problem with LVM and the milestone 8 build. It maybe how my initrd got built, any one ran into that? alright .. apparently not. I'll try that again with lvm, maybe a driver didn't get included. Any one has anything to talk about? is IPSec working? JL: yes, so far everything seems ok GW: did you run stress tests JL: not for .54, but I can start one today. Steve I'll mail you my audit changes, I made alot. I'll run stress test with those audit changed before I leave today SG: ok JL: I have not seen any problems in that regard GW: to the extent that we tested it JL: yes, the tests we ran so far seem ok Beta / Rawhide update --------------------- GW: any problems with the current beta. I think the install went smoothly KW: netlabel tools are now in beta, so I updated the kickstart. The latest beta, does it already have all pieces needed for labeled ipsec, or we need other pieces. JL: I think we updated the policy. but that might have been the previous beta KW: the latest has the 2.4 policy, so that should have all the pieces, if not please complain GW: so you shouldn't get anything out of rawhide now JL: no we shouldn't KW: At this stage, we should be able to use just beta, maybe get a kernel, but things should be in beta SELinux base update ------------------- MLS policy issues ------------------ GW: Any policy issue? KW: I am unable to login in enforcing mode for level other than non system low, as range s1-s1, I also tried local login GW: I set an ealuser to have middle range KW: and that worked for you to login with? GW: yes KW: ok, it may be something I am doing wrong MA: some of your early KS script, you were creating user with 255 categories, is that fixed KW: I fixed that a while ago. I had to hardcode it in since the label translation daemon is not running at that point. GW: I loaded james level selection on my box, but I could not get the policy built. JA: obviously the rpm built. the policy bit already got in RH. if you get a really recent version from them that should work. GW: I grabbed latest rawhide policy Saturday or yesterday, and I used your libselinux. when I log in as root it will prompt me. I added this stuff to selinux module, sshd and login next to the open JA: right GW: I also put the debug stuff to tell you what the context is. When I put in enforcing, it would kick me out if I try lo login as root or ordinary user. I need to look at it and do some analysis. Do you expect people to enter an entire context there JA: just enter the level GW: also enter the translated level JA: yes. if you press return without typing anything, then it will get the default level GW: I need to play with it a bit more, it is not working as it used to in the past JA: one big difference is level selection with tty. I assume ssh would let you do that. I don't think that is the reason it logs you out. GW: I need to go see what the denial is for. If I can't get that working, I'll catch you on irc maybe JA: sure. GW: if we get that working, that'll be pretty nice to have. what about newrole patch MT: I sent out latest patches on the 2nd. It is broken up into smaller more readable pieces. The change was adding in the preserve environment option using the -p option when you newrole like when you su. That new functionality caused better changes in the code. I have not seen any replies to that yet, so if anyone on the call can read it, that would be excellent. By the way, it looks like the list duplicated my sends, so there is only 8 emails, not 16 to read. PAM, Newrole & VFS polyinstantiation ------------------------------------ GW: Anything on polyinstantiation. Actually, I am wondering if maybe that is what is causing the logout. KW: I haven't changed that recently in KS. one thing to watch out with polyinstantiation is that it is fragile. you need to make sure the home directory has the right level if you change it. if it is at the wrong level, it will be messed up and won't be fixed if you log in again GW: maybe it's polyinstantiation that messed me up. I need to think about that. Also, I was able to kill my system with audit messages with the self tests, not sure what caused that. LS: I had the same problem. MT: I saw that before, I think I had to fix the context of the file it was writing to LS: It may be that, because I did a relabel and that's when it happened SG: in the kernel there is supposed to be a fix that audit doesn't audit itself GW: I am not clear that is what's happening, is this bug worthy? MT: audit gets sent AVC messages, maybe if it is getting avc denial ..well .. I'll take a look at that GW: we'll do more investigation and not open a bug yet unless RH wants that SG: it really is a design preference. audit doesn't audit itself, but selinux is a different subsystem and it is not aware of that, so it might audit the audit system. MT: seems like it is going in an infinite loop. GW: we'll recreate it and open a bug on it. DW: I would think it would kill the audit daemon GW: no, it was pretty much alive SG: I want to think there is a control that admins can set in the config file, let me look at that .. disk_error_action, that might help. it is set to suspend for me here MT: mine is currently set to single SG: I think it would trigger a disk error action DW: disk error action will cause AVC, so that is a problem KW: KS sets it to single option DW: bet the policy does not allow you to drop to single user mode; if so, this is a bug. SG: need to halt the action, and send an email DW: I think it can do that ... Steve, we'll review audit policy tomorrow to see it behaves properly GW: I want to go read audit daemon pid file, and can't do that as secadm DW: you're running at system high? GW: I think it is ... we need to test these issues now .. good we are hitting this rather than customers SG: are you writing this in python, I think you can do get status of audit system using lib-audit. you have to have audit capabilities in case something fails. GW: I'll try that SG: I believe it is audit-status GW: you think it is reliable? SG: The only time it is not reliable is if auditd died due to segfault and still didn't tell the kernel that happened, in this case, there is a window when it is not accurate GW: ok, I'll try that SG: that is what pam is doing I think. if pid is 0 then either kernel detected no auditd or auditd shut itself down cleanly. GW: is there way to say it died badly SG: the next time the kernel sends an audit msg it would know. I would think when a process dies, kernel would know. It is a matter of connecting dots and saying auditd died. GW: I think it is sufficient to check it this way since this will be a periodic test. let me try that and see how well that works MT: I am playing around with python audit and trying to figure out how to use it. audit_is_enabled is a function that needs one argument, but is there documentation on what that needs to be? SG: I added man pages, but I am not finished adding that DW: semanage uses audit system, so there might be code to look at there. Audit ------ Print ------ MA: Now that Eduardo is asking me, I just started going back to look at that more. I'll check out those test cases that he brought up. DW: policy for range stuff should be out, it just came out today. GW: so we should be pulling that policy from rawhide DW: yeah, for this one SG: general warning, rawhide is starting to diverge from main rhel GW: we basically should be getting away from installing from anywhere but beta. we need to be clear on what packages to install, like aide JA: well, aide in rawhide is controlled by someone else out of RH, so the official aide is the one we have with beta GW: I am running the one on your page james JA: yes that is the correct one GW: pam, aide and the kernel are to be updated on top of beta. what about the iptables packages? SG: i think the one in the 27 beta is the one in the yum repo, the name, version and release should be identical. In rhel5 branch, we put the patches for iptables. GW: ok, great... so any other things we need KW: the kickstart script, which will not be available in RH until much later. GW: if folks know of additional packages bring them up on the list CIPSO ------ GW: since paul is not here, and I think cipso seems ok we'll skip this now IPsec ------ GW: How's ipsec? JL: I did testing on the .53 kernel, I ran labeled and unlabeled ipsec. everything passed fine, so I'll do that tonight on .54. GW: is MLS working ok JL: working ok according to the policy. I haven't seen anything that I think is incorrect so far, as far as mls is concerned that is DG: venkat gave me update, there is patch coming out tomorrow morning. the SA selection, and .. those should be out tomorrow GW: ok, thanks Darryl. so we need those bits in before we do comprehensive testing. do we know when will that be in the kernel, beta or lspp kernel. SG: Is Eric on the line? JL: I have a question, is there a mechanism to toggle accept or reject unlabeled packets. when I set labeled ipsec, nothing unlabeled is accepted. I know we talked about a toggle option, anyone knows where that is? DG: I am not sure, probably send a message to Venkat on the list. JL: Ok, I'll do that SG: Back to your question George, we are still able to pull patches to kernel. that's still open for us to use. I would like to get out of the business of lspp kernels. the pre-requisite is to get development done and there are still stuff to be tested, we'll build that and do whatever it takes GW: so we'll expect one more lspp kernel with venkat's work SG: as soon as it looks stable, we'll pull it in GW: ok, so on the next kernel .55, we need to really hammer it hard for ipsec stuff. JL: and I'll send that audit stuff GW: how is that going JL: good, I'm done, just need to test it. SG: one thing to test is turn audit system off and see if audit messages still come through. some systems don't check the audit-enabled state before they send messages. GW: should we compile audit out of the kernel as well SG: yes, probably before it goes upstream GW: So check audit enabled, audit off, and audit compiled out of kernel completely. Labeled networking stabilization -------------------------------- xinetd ------- GW: word on xinetd SG: no KW: is there specific examples of how to set sshd with xinetd. I have not seen examples on how to configure that. GW: have you used sshd JL: I have only used sshd .. KW: sshd is supposed to break with unlabeled unless we have that fix from xinetd. Self tests ----------- GW: Matt has been asking me to release what I have available. I need to do something different from how I am checking auditd, but I'll put what I have out so people can see it. Matt I'll do that tomorrow rather than this evening. SG: does the RBAC self test try to do anything with RBAC? do newrole or something like that GW: no, but it can SG: did you come up with a list of actions for it to do to verify it is working correctly GW: no, it is checking status of selinux and audit now. but we can try to do newrole and try to violate the policy SG: I think you would want to try to do something not allowed to make sure it is not in permissive, other than just checking the mode. Try to crash into the wall to make sure the access mechanism is working regardless of what the status says GW: I can try that, anything else to try SG: I think you would want to change role for something you can and can't change into GW: ok SG: something else I was curious about. In Security Target (ST) do you talk about "pie" randomization KW: if selinux adds restrictions on binaries, then it should be configurable SG: ok, just curious if you made claims about it or not. if you did, I am thinking there might be enhancements to amtu, but if you didn't make any claims, then don't worry about it Cron, tmpwatch, mail, etc. --------------------------- JA: I made some changes for cron to do the range checking and spoke with Dan. I made the /etc/context contain security check. I think that is roughly ready to go. I'll do some more testing and send to Dan for approval. GW: so that's another package we want to pick up early before it goes to beta, so we can test on JA: right, what I wanted to point out earlier is to not get packages from rawhide since they are maintained by others. MA: so there is no plan to incorporate your changes in fedora extra packages JA: ... SG: upstream might be thinking to do a release candidate. Maybe we should submit that man page change to them MA: I can submit that to them .. SG: if you do that today or tomorrow, it will probably go in same release MA: that reminds me I owe you a man page for cups. GW: anything else we need to bring up? SG: yes, Matt we were talking about changing runlevel and if that needed to be an audit event GW: I thought we decided it didn't need to be an audit event MA: I think your reasoning george was that when runlevel changes, you said audit would log a shutdown so that was sufficient. GW: right, do you agree with that klaus? that we don't need audit msg for run level changes KW: it think the rationale was that users are not allowed to change run level GW: ok, that's a more clearer answer KW: that's what it has been before, we never supported changing run levels during operations SG: ok, I just wanted to know it concluded MA: would be nice to have init show audit record for that, but it is not required, especially this late in evaluation GW: I agree, it would be nice to have. Ok, anything else? thanks everyone, let's adjourn. Bugs / remaining tasks ---------------------- Final cutoff date ------------------ From dwalsh at redhat.com Tue Nov 7 19:05:00 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 07 Nov 2006 14:05:00 -0500 Subject: [redhat-lspp] Policy for aide In-Reply-To: <454F7298.9070306@hp.com> References: <454F7298.9070306@hp.com> Message-ID: <4550D8DC.60003@redhat.com> Try this. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: aide.fc URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: aide.if URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: aide.te URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: local.te URL: From kamath at cse.psu.edu Tue Nov 7 21:54:28 2006 From: kamath at cse.psu.edu (Radhesh Kamath) Date: Tue, 7 Nov 2006 16:54:28 -0500 (EST) Subject: [redhat-lspp] Need a kernel that would run on xen Message-ID: <55977.130.203.207.239.1162936468.squirrel@130.203.207.239> Hi, I am looking for a kernel with Netlabel that would run on xen. Any pointers? Regards, radhesh Radhesh M. Kamath, Department of Computer Science and Engg., Pennsylvania State University, University Park PA 16802. From james.antill at redhat.com Tue Nov 7 21:51:36 2006 From: james.antill at redhat.com (James Antill) Date: Tue, 07 Nov 2006 16:51:36 -0500 Subject: [redhat-lspp] [PATCH] MLS context contains policy/libselinux changes Message-ID: <1162936296.26574.10.camel@code.and.org> Here is the policy changes needed for the context contains security checking in PAM and cron. -- James Antill - setsockopt(fd, IPPROTO_TCP, TCP_CONGESTION, ...); setsockopt(fd, IPPROTO_TCP, TCP_DEFER_ACCEPT, ...); setsockopt(fd, SOL_SOCKET, SO_ATTACH_FILTER, ...); -------------- next part -------------- A non-text attachment was scrubbed... Name: policy-range-checking.patch Type: text/x-patch Size: 1095 bytes Desc: MLS Range checking for cron/PAM URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From eparis at redhat.com Wed Nov 8 00:22:29 2006 From: eparis at redhat.com (Eric Paris) Date: Tue, 07 Nov 2006 19:22:29 -0500 Subject: [redhat-lspp] Need a kernel that would run on xen In-Reply-To: <55977.130.203.207.239.1162936468.squirrel@130.203.207.239> References: <55977.130.203.207.239.1162936468.squirrel@130.203.207.239> Message-ID: <1162945349.3268.28.camel@localhost.localdomain> On Tue, 2006-11-07 at 16:54 -0500, Radhesh Kamath wrote: > Hi, > > I am looking for a kernel with Netlabel that would run on xen. Any pointers? > > Regards, > radhesh > > Radhesh M. Kamath, > Department of Computer Science and Engg., > Pennsylvania State University, > University Park PA 16802. > > -- > redhat-lspp mailing list > redhat-lspp at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-lspp Give me a couple days to look over the recent IPSEC changes and I'll push xen variants (somewhere) next time I build an LSPP kernel set. -Eric From jbrindle at tresys.com Wed Nov 8 06:32:06 2006 From: jbrindle at tresys.com (Joshua Brindle) Date: Wed, 08 Nov 2006 01:32:06 -0500 Subject: [redhat-lspp] Re: [PATCH] MLS context contains policy/libselinux changes In-Reply-To: <1162936296.26574.10.camel@code.and.org> References: <1162936296.26574.10.camel@code.and.org> Message-ID: <455179E6.5060209@tresys.com> James Antill wrote: > Here is the policy changes needed for the context contains security > checking in PAM and cron. > er, where did this come from? I haven't seen any discussions about this and have no idea what its about (perhaps I've just totally missed it somehow though..) From jantill at redhat.com Wed Nov 8 06:40:05 2006 From: jantill at redhat.com (James Antill) Date: Wed, 08 Nov 2006 01:40:05 -0500 Subject: [redhat-lspp] Re: [PATCH] MLS context contains policy/libselinux changes In-Reply-To: <455179E6.5060209@tresys.com> References: <1162936296.26574.10.camel@code.and.org> <455179E6.5060209@tresys.com> Message-ID: <1162968005.5084.1.camel@code.and.org> On Wed, 2006-11-08 at 01:32 -0500, Joshua Brindle wrote: > James Antill wrote: > > Here is the policy changes needed for the context contains security > > checking in PAM and cron. > > > > er, where did this come from? I haven't seen any discussions about this > and have no idea what its about (perhaps I've just totally missed it > somehow though..) The gory details were under the thread "MLS enforcing PTYs, sshd, and newrole" -- James Antill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jbrindle at tresys.com Wed Nov 8 13:31:46 2006 From: jbrindle at tresys.com (Joshua Brindle) Date: Wed, 8 Nov 2006 08:31:46 -0500 Subject: [redhat-lspp] RE: [PATCH] MLS context contains policy/libselinux changes In-Reply-To: <1162968005.5084.1.camel@code.and.org> Message-ID: <6FE441CD9F0C0C479F2D88F959B01588514DF0@exchange.columbia.tresys.com> > From: James Antill [mailto:jantill at redhat.com] > > On Wed, 2006-11-08 at 01:32 -0500, Joshua Brindle wrote: > > James Antill wrote: > > > Here is the policy changes needed for the context > contains security > > > checking in PAM and cron. > > > > > > > er, where did this come from? I haven't seen any discussions about > > this and have no idea what its about (perhaps I've just > totally missed > > it somehow though..) > > The gory details were under the thread "MLS enforcing PTYs, > sshd, and newrole" > Ah, well that explains it, that thread was way too long and had MLS in the subject..... Any way I could get a summary/conclusion and description of the new permission? From sds at tycho.nsa.gov Wed Nov 8 14:00:19 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 08 Nov 2006 09:00:19 -0500 Subject: [redhat-lspp] RE: [PATCH] MLS context contains policy/libselinux changes In-Reply-To: <6FE441CD9F0C0C479F2D88F959B01588514DF0@exchange.columbia.tresys.com> References: <6FE441CD9F0C0C479F2D88F959B01588514DF0@exchange.columbia.tresys.com> Message-ID: <1162994419.3009.77.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-11-08 at 08:31 -0500, Joshua Brindle wrote: > > From: James Antill [mailto:jantill at redhat.com] > > > > On Wed, 2006-11-08 at 01:32 -0500, Joshua Brindle wrote: > > > James Antill wrote: > > > > Here is the policy changes needed for the context > > contains security > > > > checking in PAM and cron. > > > > > > > > > > er, where did this come from? I haven't seen any discussions about > > > this and have no idea what its about (perhaps I've just > > totally missed > > > it somehow though..) > > > > The gory details were under the thread "MLS enforcing PTYs, > > sshd, and newrole" > > > > Ah, well that explains it, that thread was way too long and had MLS in > the subject..... > > Any way I could get a summary/conclusion and description of the new > permission? If we allow users to enter a level at login time (or specify a level for a cron job), then we need to check that the Linux user was authorized for that level (based on seusers). As this gets into level comparisons, which are policy-specific, it requires a permission check to the security server. The check is applied between a context generated from the seusers entry for the user and the context modified with the user-specified level. The TE policy then authorizes it for the self relationship (since the types are the same in both contexts), and the MLS constraints ensure that the user-specified level is within the seusers-specified clearance. Same basic idea as the existing context translate permission used to similarly check the ability of the user to translate a given MLS level. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Wed Nov 8 14:04:28 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 08 Nov 2006 09:04:28 -0500 Subject: [redhat-lspp] Re: [PATCH] cron changes needed for MLS range checking (requires at least the libselinux patches) In-Reply-To: <1162936978.26574.20.camel@code.and.org> References: <1162936978.26574.20.camel@code.and.org> Message-ID: <1162994668.3009.82.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2006-11-07 at 17:02 -0500, James Antill wrote: > I think this is what we want for the cron patch. It's basically doing > the same checks as the PAM patches. It also limits what the user can > change to just the MLS range. > At the moment I've just copied the original functions that need to be > replaced, so you can see the old vs. the new. As the final commit the > old ones should probably just die. > I've also kept the name SELINUX_ROLE_TYPE, I'm not sure if it should be > changed to SELINUX_ROLE_RANGE or something else? As I understood it, you were only going to allow level specification, not user/role/domain, so it would just be SELINUX_LEVEL or MLS_LEVEL or similar. As in the pam case, you should be checking between a context for the user with the seusers-specified range and a context for the user with the user-specified level. Your patch doesn't seem to match that description - it refers to a file context as the target. Also, the function that performs the setexeccon (which you call cron_change_selinux_range) is more general - it is supposed to set the entire user context appropriately for the user on whose behalf cron is running a job. -- Stephen Smalley National Security Agency From jantill at redhat.com Wed Nov 8 20:32:39 2006 From: jantill at redhat.com (James Antill) Date: Wed, 08 Nov 2006 15:32:39 -0500 Subject: [redhat-lspp] Re: [PATCH] cron changes needed for MLS range checking (requires at least the libselinux patches) In-Reply-To: <1162994668.3009.82.camel@moss-spartans.epoch.ncsc.mil> References: <1162936978.26574.20.camel@code.and.org> <1162994668.3009.82.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1163017959.29854.12.camel@code.and.org> On Wed, 2006-11-08 at 09:04 -0500, Stephen Smalley wrote: > On Tue, 2006-11-07 at 17:02 -0500, James Antill wrote: > > I think this is what we want for the cron patch. It's basically doing > > the same checks as the PAM patches. It also limits what the user can > > change to just the MLS range. > > At the moment I've just copied the original functions that need to be > > replaced, so you can see the old vs. the new. As the final commit the > > old ones should probably just die. > > I've also kept the name SELINUX_ROLE_TYPE, I'm not sure if it should be > > changed to SELINUX_ROLE_RANGE or something else? > > As I understood it, you were only going to allow level specification, > not user/role/domain, so it would just be SELINUX_LEVEL or MLS_LEVEL or > similar. Right, that's what I meant by "if it should be changed...". After speaking with Dan today, I've changed it to MLS_LEVEL. > As in the pam case, you should be checking between a context for the > user with the seusers-specified range and a context for the user with > the user-specified level. Your patch doesn't seem to match that > description - it refers to a file context as the target. One context comes from the cron file, and one from that plus the level change as requested by the user. See cron_get_job_range(). Changing that to be the result of getseuserbyname(), matching PAM, instead of the file context would be possible ... although I'm not sure if using "root" when u->name is "*system*" is the right thing to do. > Also, the function that performs the setexeccon (which you call > cron_change_selinux_range) is more general - it is supposed to set the > entire user context appropriately for the user on whose behalf cron is > running a job. Right. Are you saying I need to call, cron_authorize_context() as well as cron_authorize_range()? I decided this wasn't required because that function is called from within get_security_context(), and instead of being able to change everything now ... they can only change the level. So we don't need to re-auth the entire security context, just the level. I'm certainly open to just checking it anyway, if you see any holes in my reasoning or if everyone would just prefer to check it twice. If that isn't what you meant, could you explain further what the problem is? -- James Antill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sds at tycho.nsa.gov Wed Nov 8 20:53:47 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 08 Nov 2006 15:53:47 -0500 Subject: [redhat-lspp] Re: [PATCH] cron changes needed for MLS range checking (requires at least the libselinux patches) In-Reply-To: <1163017959.29854.12.camel@code.and.org> References: <1162936978.26574.20.camel@code.and.org> <1162994668.3009.82.camel@moss-spartans.epoch.ncsc.mil> <1163017959.29854.12.camel@code.and.org> Message-ID: <1163019227.12241.178.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-11-08 at 15:32 -0500, James Antill wrote: > > As in the pam case, you should be checking between a context for the > > user with the seusers-specified range and a context for the user with > > the user-specified level. Your patch doesn't seem to match that > > description - it refers to a file context as the target. > > One context comes from the cron file, and one from that plus the level > change as requested by the user. See cron_get_job_range(). > Changing that to be the result of getseuserbyname(), matching PAM, > instead of the file context would be possible ... although I'm not sure > if using "root" when u->name is "*system*" is the right thing to do. The scontext is supposed to be a process context in which to run the cron job, not a file context. You are presently replacing the default scontext (extracted from u->scontext that was previously computed) with a strange mixture of the crontab file context and the user-specified range. What you want to do is to take the default scontext value, create a new context that is identical except for its range (from the environment), and apply a check between those two contexts (and the check is only needed when using a user-supplied range). BTW, you cannot continue to refer to the string returned by context_str() after performing a context_free() on the structure; you'd have to dup it first. > > Also, the function that performs the setexeccon (which you call > > cron_change_selinux_range) is more general - it is supposed to set the > > entire user context appropriately for the user on whose behalf cron is > > running a job. > > Right. Are you saying I need to call, cron_authorize_context() as well > as cron_authorize_range()? > I decided this wasn't required because that function is called from > within get_security_context(), and instead of being able to change > everything now ... they can only change the level. So we don't need to > re-auth the entire security context, just the level. > I'm certainly open to just checking it anyway, if you see any holes in > my reasoning or if everyone would just prefer to check it twice. > > If that isn't what you meant, could you explain further what the > problem is? That is what I meant, but if it is being checked earlier and the crontab file cannot be replaced in the interim without going through the check again, it may be ok to not recheck in your patch. -- Stephen Smalley National Security Agency From jantill at redhat.com Wed Nov 8 21:57:01 2006 From: jantill at redhat.com (James Antill) Date: Wed, 08 Nov 2006 16:57:01 -0500 Subject: [redhat-lspp] Re: [PATCH] cron changes needed for MLS range checking (requires at least the libselinux patches) In-Reply-To: <1163019227.12241.178.camel@moss-spartans.epoch.ncsc.mil> References: <1162936978.26574.20.camel@code.and.org> <1162994668.3009.82.camel@moss-spartans.epoch.ncsc.mil> <1163017959.29854.12.camel@code.and.org> <1163019227.12241.178.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1163023021.29854.15.camel@code.and.org> On Wed, 2006-11-08 at 15:53 -0500, Stephen Smalley wrote: > The scontext is supposed to be a process context in which to run the > cron job, not a file context. You are presently replacing the default > scontext (extracted from u->scontext that was previously computed) with > a strange mixture of the crontab file context and the user-specified > range. What you want to do is to take the default scontext value, > create a new context that is identical except for its range (from the > environment), and apply a check between those two contexts (and the > check is only needed when using a user-supplied range). Ok, I've used u->scontext instead of the file context now. I've also renamed the variables. And the check should only happen if they specify a different level. > BTW, you cannot > continue to refer to the string returned by context_str() after > performing a context_free() on the structure; you'd have to dup it > first. Right, stupid mistake. Fixed that too. -- James Antill -------------- next part -------------- A non-text attachment was scrubbed... Name: vixie-cron-4.1-_60-SELinux-contains-range.patch Type: text/x-patch Size: 7514 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sds at tycho.nsa.gov Wed Nov 8 22:13:10 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 08 Nov 2006 17:13:10 -0500 Subject: [redhat-lspp] Re: [PATCH] cron changes needed for MLS range checking (requires at least the libselinux patches) In-Reply-To: <1163023021.29854.15.camel@code.and.org> References: <1162936978.26574.20.camel@code.and.org> <1162994668.3009.82.camel@moss-spartans.epoch.ncsc.mil> <1163017959.29854.12.camel@code.and.org> <1163019227.12241.178.camel@moss-spartans.epoch.ncsc.mil> <1163023021.29854.15.camel@code.and.org> Message-ID: <1163023990.12241.231.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-11-08 at 16:57 -0500, James Antill wrote: > On Wed, 2006-11-08 at 15:53 -0500, Stephen Smalley wrote: > > > The scontext is supposed to be a process context in which to run the > > cron job, not a file context. You are presently replacing the default > > scontext (extracted from u->scontext that was previously computed) with > > a strange mixture of the crontab file context and the user-specified > > range. What you want to do is to take the default scontext value, > > create a new context that is identical except for its range (from the > > environment), and apply a check between those two contexts (and the > > check is only needed when using a user-supplied range). > > Ok, I've used u->scontext instead of the file context now. I've also > renamed the variables. And the check should only happen if they specify > a different level. > > > BTW, you cannot > > continue to refer to the string returned by context_str() after > > performing a context_free() on the structure; you'd have to dup it > > first. > > Right, stupid mistake. Fixed that too. Looks better. A few nits: +static int +cron_authorize_range +( + security_context_t scontext, + security_context_t file_context s/file_context/ucontext/ +) +{ +#ifdef WITH_SELINUX + struct av_decision avd; + int retval; + unsigned int bit = CONTEXT__CONTAINS; + /* + * Since crontab files are not directly executed, + * crond must ensure that the crontab range has + * a context that is appropriate for the context of + * the user cron job. It performs an entrypoint + * permission check for this purpose. cut-and-paste + */ + retval = security_compute_av(scontext, file_context, s/file_context/ucontext/ +static int cron_get_job_range( user *u, security_context_t *ucontextp, + char **jobenv ) +{ + char *sroletype; s/sroletype/range/ + if ( (sroletype = env_get("MLS_LEVEL",jobenv)) != 0L ) + { + char crontab[MAX_FNAME]; + context_t ccon; + + if ( strcmp(u->name,"*system*") == 0 ) + strncpy(crontab, u->tabname, MAX_FNAME); + else + snprintf(crontab, MAX_FNAME, "%s/%s", CRONDIR, u->tabname); + + if (!(ccon = context_new(u->scontext))) + { + if ( security_getenforce() > 0 ) + { + log_it(u->name, + getpid(), "context_new FAILED for SELINUX_ROLE_TYPE", s/SELINUX_ROLE_TYPE/MLS_LEVEL/ + sroletype + ); + return -1; + } else + { + log_it(u->name, + getpid(), + "context_new FAILED but SELinux in permissive mode, continuing " + "- SELINUX_ROLE_TYPE=", sroletype + ); + return 0; + } I wouldn't put tests of security_getenforce() on anything other than permission denials (which avc_has_perm would do internally for you if you were to use it instead of security_compute_av). If context_new() fails, it means you are out of memory, so permissive mode or not, you are going to die. + + *ucontextp = strdup(context_str(ccon)); Needs checking of both the intermediate result (context_str return value) and strdup to avoid seg faulting on NULL. -- Stephen Smalley National Security Agency From jantill at redhat.com Tue Nov 7 21:57:56 2006 From: jantill at redhat.com (James Antill) Date: Tue, 07 Nov 2006 16:57:56 -0500 Subject: [redhat-lspp] [PATCH] libselinux MLS range context contains for PAM/cron Message-ID: <1162936676.26574.15.camel@code.and.org> Here is the libselinux changes needed to do the security context contains checks for PAM and cron. -- James Antill -------------- next part -------------- A non-text attachment was scrubbed... Name: selinux-range-checking.patch Type: text/x-patch Size: 987 bytes Desc: libselinux MLS range checking bits, for cron and PAM URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jantill at redhat.com Tue Nov 7 22:02:58 2006 From: jantill at redhat.com (James Antill) Date: Tue, 07 Nov 2006 17:02:58 -0500 Subject: [redhat-lspp] [PATCH] cron changes needed for MLS range checking (requires at least the libselinux patches) Message-ID: <1162936978.26574.20.camel@code.and.org> I think this is what we want for the cron patch. It's basically doing the same checks as the PAM patches. It also limits what the user can change to just the MLS range. At the moment I've just copied the original functions that need to be replaced, so you can see the old vs. the new. As the final commit the old ones should probably just die. I've also kept the name SELINUX_ROLE_TYPE, I'm not sure if it should be changed to SELINUX_ROLE_RANGE or something else? -- James Antill -------------- next part -------------- A non-text attachment was scrubbed... Name: vixie-cron-4.1-_60-SELinux-contains-range.patch Type: text/x-patch Size: 7775 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jantill at redhat.com Wed Nov 8 23:47:25 2006 From: jantill at redhat.com (James Antill) Date: Wed, 08 Nov 2006 18:47:25 -0500 Subject: [redhat-lspp] Re: [PATCH] cron changes needed for MLS range checking (requires at least the libselinux patches) In-Reply-To: <1163023990.12241.231.camel@moss-spartans.epoch.ncsc.mil> References: <1162936978.26574.20.camel@code.and.org> <1162994668.3009.82.camel@moss-spartans.epoch.ncsc.mil> <1163017959.29854.12.camel@code.and.org> <1163019227.12241.178.camel@moss-spartans.epoch.ncsc.mil> <1163023021.29854.15.camel@code.and.org> <1163023990.12241.231.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1163029645.29854.20.camel@code.and.org> On Wed, 2006-11-08 at 17:13 -0500, Stephen Smalley wrote: > Looks better. A few nits: > + /* > + * Since crontab files are not directly executed, > + * crond must ensure that the crontab range has > + * a context that is appropriate for the context of > + * the user cron job. It performs an entrypoint > + * permission check for this purpose. > > cut-and-paste I did alter it a little, but I've altered it more now :). > I wouldn't put tests of security_getenforce() on anything other than > permission denials Done. > + > + *ucontextp = strdup(context_str(ccon)); > > Needs checking of both the intermediate result (context_str return > value) and strdup to avoid seg faulting on NULL. Ahh, I had copied the assumption that context_x() doesn't fail from PAM ... I assumed it preallocated in context_new(). I'll fix PAM too. Attached is the latest cron patch. -- James Antill -------------- next part -------------- A non-text attachment was scrubbed... Name: vixie-cron-4.1-_60-SELinux-contains-range.patch Type: text/x-patch Size: 7464 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sds at tycho.nsa.gov Thu Nov 9 15:07:14 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 09 Nov 2006 10:07:14 -0500 Subject: [redhat-lspp] Re: [PATCH] cron changes needed for MLS range checking (requires at least the libselinux patches) In-Reply-To: <1163029645.29854.20.camel@code.and.org> References: <1162936978.26574.20.camel@code.and.org> <1162994668.3009.82.camel@moss-spartans.epoch.ncsc.mil> <1163017959.29854.12.camel@code.and.org> <1163019227.12241.178.camel@moss-spartans.epoch.ncsc.mil> <1163023021.29854.15.camel@code.and.org> <1163023990.12241.231.camel@moss-spartans.epoch.ncsc.mil> <1163029645.29854.20.camel@code.and.org> Message-ID: <1163084834.12241.293.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-11-08 at 18:47 -0500, James Antill wrote: > Attached is the latest cron patch. diff -rup vixie-cron-4.1-orig/security.c vixie-cron-4.1/security.c --- vixie-cron-4.1-orig/security.c 2006-11-02 22:28:04.000000000 -0500 +++ vixie-cron-4.1/security.c 2006-11-08 17:35:27.000000000 -0500 +static int +cron_authorize_range +( + security_context_t scontext, + security_context_t ucontext +) +{ +#ifdef WITH_SELINUX + struct av_decision avd; + int retval; + unsigned int bit = CONTEXT__CONTAINS; + /* + * Since crontab files are not directly executed, + * so crond must ensure that any user specified range + * is allowed by the default users range. It performs + * an entrypoint permission check for this purpose. + */ Still not accurate. This check is quite different in purpose and rationale than the entrypoint check; it has nothing to do with the fact that crontab files are not directly executed. It is just a check of whether the user-specified level falls within the seusers-specified range for that Linux user. +static int cron_change_selinux_range( user *u, + security_context_t ucontext ) +{ + if ( is_selinux_enabled() <= 0 ) + return 0; + + if ( u->scontext == 0L ) + { + if (security_getenforce() > 0) + { + log_it( u->name, getpid(), + "NULL security context for user", + "" + ); + return -1; + }else + { + log_it( u->name, getpid(), + "NULL security context for user, " + "but SELinux in permissive mode, continuing", + "" + ); + return 0; + } Another case where I don't understand why enforcing/permissive makes any difference. + } + + if ( ucontext && strcmp(u->scontext, ucontext) ) + { + if ( ! cron_authorize_range( u->scontext, ucontext )) + { + if ( security_getenforce() > 0 ) + { + syslog(LOG_ERR, + "CRON (%s) ERROR:" + "Unauthorized exec context to SELINUX_ROLE_TYPE %s for user", + u->name, (char*)ucontext + ); Still refers to SELINUX_ROLE_TYPE in the log message. + return -1; + } else + { + syslog(LOG_INFO, + "CRON (%s) WARNING:" + "Unauthorized exec context to SELINUX_ROLE_TYPE %s for user," + " but SELinux in permissive mode, continuing", + u->name, (char*)ucontext + ); Ditto. + } + } + } + + if ( setexeccon(ucontext) < 0 ) + { + if (security_getenforce() > 0) + { + syslog(LOG_ERR, + "CRON (%s) ERROR:" + "Could not set exec context to %s for user", + u->name, (char*)ucontext + ); + + return -1; + } Likely want to log something in the else case too so you don't just silently proceed under crond's own context. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Thu Nov 9 15:37:31 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 09 Nov 2006 10:37:31 -0500 Subject: [redhat-lspp] Re: [PATCH] libselinux MLS range context contains for PAM/cron In-Reply-To: <1162936676.26574.15.camel@code.and.org> References: <1162936676.26574.15.camel@code.and.org> Message-ID: <1163086651.12241.313.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2006-11-07 at 16:57 -0500, James Antill wrote: > Here is the libselinux changes needed to do the security context > contains checks for PAM and cron. Index: libselinux/include/selinux/av_permissions.h =================================================================== --- libselinux/include/selinux/av_permissions.h (revision 2076) +++ libselinux/include/selinux/av_permissions.h (working copy) @@ -896,3 +896,4 @@ #define KEY__SETATTR 0x00000020UL #define KEY__CREATE 0x00000040UL #define CONTEXT__TRANSLATE 0x00000001UL +#define CONTEXT__CONTAINS 0x00000002UL Index: libselinux/src/av_perm_to_string.h =================================================================== --- libselinux/src/av_perm_to_string.h (revision 2076) +++ libselinux/src/av_perm_to_string.h (working copy) @@ -266,3 +266,4 @@ S_(SECCLASS_KEY, KEY__SETATTR, "setattr") S_(SECCLASS_KEY, KEY__CREATE, "create") S_(SECCLASS_CONTEXT, CONTEXT__TRANSLATE, "translate") + S_(SECCLASS_CONTEXT, CONTEXT__CONTAINS, "contains") This patch is obviously fine as long as the corresponding policy patch is accepted. Acked-by: Stephen Smalley -- Stephen Smalley National Security Agency From jantill at redhat.com Thu Nov 9 15:40:50 2006 From: jantill at redhat.com (James Antill) Date: Thu, 09 Nov 2006 10:40:50 -0500 Subject: [redhat-lspp] Re: [PATCH] cron changes needed for MLS range checking (requires at least the libselinux patches) In-Reply-To: <1163084834.12241.293.camel@moss-spartans.epoch.ncsc.mil> References: <1162936978.26574.20.camel@code.and.org> <1162994668.3009.82.camel@moss-spartans.epoch.ncsc.mil> <1163017959.29854.12.camel@code.and.org> <1163019227.12241.178.camel@moss-spartans.epoch.ncsc.mil> <1163023021.29854.15.camel@code.and.org> <1163023990.12241.231.camel@moss-spartans.epoch.ncsc.mil> <1163029645.29854.20.camel@code.and.org> <1163084834.12241.293.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1163086850.29854.26.camel@code.and.org> On Thu, 2006-11-09 at 10:07 -0500, Stephen Smalley wrote: > On Wed, 2006-11-08 at 18:47 -0500, James Antill wrote: > > Attached is the latest cron patch. > > diff -rup vixie-cron-4.1-orig/security.c vixie-cron-4.1/security.c > --- vixie-cron-4.1-orig/security.c 2006-11-02 22:28:04.000000000 -0500 > +++ vixie-cron-4.1/security.c 2006-11-08 17:35:27.000000000 -0500 > +static int > +cron_authorize_range > +( > + security_context_t scontext, > + security_context_t ucontext > +) > +{ > +#ifdef WITH_SELINUX > + struct av_decision avd; > + int retval; > + unsigned int bit = CONTEXT__CONTAINS; > + /* > + * Since crontab files are not directly executed, > + * so crond must ensure that any user specified range > + * is allowed by the default users range. It performs > + * an entrypoint permission check for this purpose. > + */ > > Still not accurate. This check is quite different in purpose and > rationale than the entrypoint check; it has nothing to do with the fact > that crontab files are not directly executed. It is just a check of > whether the user-specified level falls within the seusers-specified > range for that Linux user. Ok. I've changed the comment again. > +static int cron_change_selinux_range( user *u, > + security_context_t ucontext ) > +{ > + if ( is_selinux_enabled() <= 0 ) > + return 0; > + > + if ( u->scontext == 0L ) > + { > + if (security_getenforce() > 0) > + { > + log_it( u->name, getpid(), > + "NULL security context for user", > + "" > + ); > + return -1; > + }else > + { > + log_it( u->name, getpid(), > + "NULL security context for user, " > + "but SELinux in permissive mode, continuing", > + "" > + ); > + return 0; > + } > > Another case where I don't understand why enforcing/permissive makes any > difference. Because without enforcing mode we just ignore the problem and continue, with it we error out. I think this is more of a theoretical assert type problem anyway, but still. > Still refers to SELINUX_ROLE_TYPE in the log message. Fixed. > + if ( setexeccon(ucontext) < 0 ) > + { > + if (security_getenforce() > 0) > + { > + syslog(LOG_ERR, > + "CRON (%s) ERROR:" > + "Could not set exec context to %s for user", > + u->name, (char*)ucontext > + ); > + > + return -1; > + } > > Likely want to log something in the else case too so you don't just > silently proceed under crond's own context. Done. -- James Antill - setsockopt(fd, IPPROTO_TCP, TCP_CONGESTION, ...); setsockopt(fd, IPPROTO_TCP, TCP_DEFER_ACCEPT, ...); setsockopt(fd, SOL_SOCKET, SO_ATTACH_FILTER, ...); -------------- next part -------------- A non-text attachment was scrubbed... Name: vixie-cron-4.1-_60-SELinux-contains-range.patch Type: text/x-patch Size: 7696 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sds at tycho.nsa.gov Thu Nov 9 15:57:48 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 09 Nov 2006 10:57:48 -0500 Subject: [redhat-lspp] Re: [PATCH] cron changes needed for MLS range checking (requires at least the libselinux patches) In-Reply-To: <1163086850.29854.26.camel@code.and.org> References: <1162936978.26574.20.camel@code.and.org> <1162994668.3009.82.camel@moss-spartans.epoch.ncsc.mil> <1163017959.29854.12.camel@code.and.org> <1163019227.12241.178.camel@moss-spartans.epoch.ncsc.mil> <1163023021.29854.15.camel@code.and.org> <1163023990.12241.231.camel@moss-spartans.epoch.ncsc.mil> <1163029645.29854.20.camel@code.and.org> <1163084834.12241.293.camel@moss-spartans.epoch.ncsc.mil> <1163086850.29854.26.camel@code.and.org> Message-ID: <1163087868.12241.327.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2006-11-09 at 10:40 -0500, James Antill wrote: > Because without enforcing mode we just ignore the problem and continue, > with it we error out. I think this is more of a theoretical assert type > problem anyway, but still. That's my point - it seems like it is a bug regardless of whether we are permissive or enforcing, and should thus always return -1. I'd only expect security_getenforce() to make a difference for error handling on permission checks. Anyway, the patch looks sane at this point, although I'm not completely clear how it integrates into the existing pile of selinux-related patches in vixie-cron (it would help to consolidate them). What is your plan on the client (crontab program) side? The old patch instrumented it to automatically insert a SELINUX_ROLE_TYPE= definition with the caller's context if a certain option was used to crontab; will you replace that with your new MLS_LEVEL= definition and the caller's current range or just drop it altogether and require the user to manually specify it in the crontab file? Am I correct in understanding that there can only be one MLS_LEVEL= definition per crontab file (for all cron jobs in that crontab)? Can it go anywhere in the crontab file? -- Stephen Smalley National Security Agency From jantill at redhat.com Thu Nov 9 16:28:00 2006 From: jantill at redhat.com (James Antill) Date: Thu, 09 Nov 2006 11:28:00 -0500 Subject: [redhat-lspp] Re: [PATCH] cron changes needed for MLS range checking (requires at least the libselinux patches) In-Reply-To: <1163087868.12241.327.camel@moss-spartans.epoch.ncsc.mil> References: <1162936978.26574.20.camel@code.and.org> <1162994668.3009.82.camel@moss-spartans.epoch.ncsc.mil> <1163017959.29854.12.camel@code.and.org> <1163019227.12241.178.camel@moss-spartans.epoch.ncsc.mil> <1163023021.29854.15.camel@code.and.org> <1163023990.12241.231.camel@moss-spartans.epoch.ncsc.mil> <1163029645.29854.20.camel@code.and.org> <1163084834.12241.293.camel@moss-spartans.epoch.ncsc.mil> <1163086850.29854.26.camel@code.and.org> <1163087868.12241.327.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1163089680.29854.35.camel@code.and.org> On Thu, 2006-11-09 at 10:57 -0500, Stephen Smalley wrote: > On Thu, 2006-11-09 at 10:40 -0500, James Antill wrote: > > Because without enforcing mode we just ignore the problem and continue, > > with it we error out. I think this is more of a theoretical assert type > > problem anyway, but still. > > That's my point - it seems like it is a bug regardless of whether we are > permissive or enforcing, and should thus always return -1. I'd only > expect security_getenforce() to make a difference for error handling on > permission checks. Well get_security_context() does the same thing if fgetfilecon(), getseuserbyname()/get_default_context_with_level() or cron_authorize_context() fail (which would lead to u->scontext being NULL, AIUI), so I really wouldn't want to change it unless all those changed in some way. > Anyway, the patch looks sane at this point, although I'm not completely > clear how it integrates into the existing pile of selinux-related > patches in vixie-cron (it would help to consolidate them). I can't really do that, easily. > What is your plan on the client (crontab program) side? The old patch > instrumented it to automatically insert a SELINUX_ROLE_TYPE= definition > with the caller's context if a certain option was used to crontab; will > you replace that with your new MLS_LEVEL= definition and the caller's > current range or just drop it altogether and require the user to > manually specify it in the crontab file? Atm. I've got a patch which changes the crontab command to only add the level when -s is specified. > Am I correct in understanding > that there can only be one MLS_LEVEL= definition per crontab file (for > all cron jobs in that crontab)? Yes. > Can it go anywhere in the crontab file? Yes. -- James Antill - setsockopt(fd, IPPROTO_TCP, TCP_CONGESTION, ...); setsockopt(fd, IPPROTO_TCP, TCP_DEFER_ACCEPT, ...); setsockopt(fd, SOL_SOCKET, SO_ATTACH_FILTER, ...); -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From cpebenito at tresys.com Thu Nov 9 16:49:29 2006 From: cpebenito at tresys.com (Christopher J. PeBenito) Date: Thu, 09 Nov 2006 11:49:29 -0500 Subject: [redhat-lspp] Re: [PATCH] libselinux MLS range context contains for PAM/cron In-Reply-To: <1163086651.12241.313.camel@moss-spartans.epoch.ncsc.mil> References: <1162936676.26574.15.camel@code.and.org> <1163086651.12241.313.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1163090969.18181.89.camel@sgc> On Thu, 2006-11-09 at 10:37 -0500, Stephen Smalley wrote: > On Tue, 2006-11-07 at 16:57 -0500, James Antill wrote: > > Here is the libselinux changes needed to do the security context > > contains checks for PAM and cron. > > Index: libselinux/include/selinux/av_permissions.h [cut] > +#define CONTEXT__CONTAINS 0x00000002UL > Index: libselinux/src/av_perm_to_string.h [cut] > + S_(SECCLASS_CONTEXT, CONTEXT__CONTAINS, "contains") > > This patch is obviously fine as long as the corresponding policy patch > is accepted. The policy patch is fine, I was just waiting for the code to be accepted and committed. -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 From efleury at br.ibm.com Thu Nov 9 17:28:27 2006 From: efleury at br.ibm.com (Eduardo Madeira Fleury) Date: Thu, 9 Nov 2006 15:28:27 -0200 Subject: [redhat-lspp] RHEL5 10/27 + KS -- Run_init is locking user account Message-ID: <200611091528.27562.efleury@br.ibm.com> Hey all, I think I've found a bug. Using RHEL5 Server 10/27 refresh installed with the KS script v0.9 I figured out that executing run_init always increment the pam_tally2 failure count for the user in question, which means one day or another the user's account gets locked, currently this happens after 6 successfull run_init calls. I haven't had the chance to test with a system installed without the KS script or in the new refresh. If anyone has the chance, would please try and report results? If this is really a bug I'll open a bugzilla. To reproduce: Login as an admin user (ie. one that logs as staff_u. From now on I'll call it "tux"). # /bin/su - # newrole -r sysadm_r -t sysadm_t Clear failog # pam_tally2 --user tux --reset Check it's cleared (failures = 0) # pam_tally2 --user tux # run_init service Type in the correct password, you should see run_init usage string. # pam_tally2 --user tux ... shows 1 failure. And, if you repeat the run_init command 5 or 6 times the tux account will be locked and then you must unlock it using # pam_tally2 --user tux --reset Regards, -- Eduardo M. Fleury IBM Linux Technology Center Brazil Mobile: +55-19-81224410 email/sametime: efleury at br.ibm.com From mra at hp.com Thu Nov 9 21:55:14 2006 From: mra at hp.com (Matt Anderson) Date: Thu, 9 Nov 2006 14:55:14 -0700 Subject: [redhat-lspp] LSPP kickstart patch In-Reply-To: <20061030222253.GB30812@w-m-p.com> References: <20061030222253.GB30812@w-m-p.com> Message-ID: <20061109215514.GA23358@ldl.lart> Attached is a patch to the kickstart config which sets up Cups at install time. The patch contains the changes to cupsd.conf which are needed, but assumes that lspp-config/lspp has been populated with client.conf, mime.convs and mime.types from my online documentation: http://free.linux.hp.com/~mra/docs/ -matt -------------- next part -------------- diff --git a/lspp-config.spec.in b/lspp-config.spec.in index 0643aa2..1dcc333 100644 --- a/lspp-config.spec.in +++ b/lspp-config.spec.in @@ -35,6 +35,7 @@ rm -rf $RPM_BUILD_ROOT %attr(0644,root,root) %{_datadir}/lspp/*.defs %attr(0644,root,root) %{_datadir}/lspp/*.conf %attr(0644,root,root) %{_datadir}/lspp/*.te +%attr(0644,root,root) %{_datadir}/lspp/mime.* %attr(0644,root,root) %{_datadir}/lspp/sshd_config %attr(0755,root,root) %dir %{_datadir}/doc/@@NAME@@-%{version} %attr(0644,root,root) %{_datadir}/doc/@@NAME@@-%{version}/* diff --git a/lspp-config/bin/lspp-eal4-config.in b/lspp-config/bin/lspp-eal4-config.in index abf56d7..e63426f 100755 --- a/lspp-config/bin/lspp-eal4-config.in +++ b/lspp-config/bin/lspp-eal4-config.in @@ -206,19 +206,25 @@ ConfigureCups() { if ! grep -q '^RunAsUser Yes$' $CupsConf then - if egrep -q '^(User|Group)' $CupsConf \ - || ! grep -q '^#Group' $CupsConf + if egrep -q '^(User|Group)' $CupsConf then Warn "Warning: $CupsConf was changed from default, can't modify it" _FAILURE=1 fi - sed '/#Group/{ + sed 's/Listen localhost/#Listen localhost/; + s/Browsing On/Browsing Off/; + /^SystemGroup/{ aUser lp aGroup sys aRunAsUser Yes +aClassification mls +aClassifyOverride no }' < $CupsConf > $CupsConf.new Replace $CupsConf removing $CupsConf.new + Replace $_CUPS_DEST/$_CUPS_CLIENT with $_BASE/$_CUPS_CLIENT + Replace $_CUPS_DEST/$_CUPS_MIMET with $_BASE/$_CUPS_MIMET + Replace $_CUPS_DEST/$_CUPS_MIMEC with $_BASE/$_CUPS_MIMEC fi else Log "reconfiguring CUPS declined" @@ -732,7 +738,7 @@ Please read the documentation before pro ConfigureFTP ConfigureAudit ConfigurePostfix - #ConfigureCups + ConfigureCups ConfigurePolyinstantiation DisableUsbfs SetRunLevel 3 @@ -1011,6 +1017,10 @@ readonly _AUDITD_CONF=auditd.conf readonly _VSFTPD_CONF=/etc/vsftpd/vsftpd.conf readonly _NAMESPACE_CONF=namespace.conf readonly _LSPP_POLICY=lspp_policy.te +readonly _CUPS_CLIENT=client.conf +readonly _CUPS_MIMET=mime.types +readonly _CUPS_MIMEC=mime.convs +readonly _CUPS_DEST=/etc/cups # this will get the name of the arch-dependent packages file # and go readonly in Main() From loulwas at us.ibm.com Fri Nov 10 20:44:41 2006 From: loulwas at us.ibm.com (Loulwa Salem) Date: Fri, 10 Nov 2006 14:44:41 -0600 Subject: [redhat-lspp] latest rhel refresh and .54 kernel Message-ID: <4554E4B9.5050504@us.ibm.com> Hi, Do we still need to update the kernel to the lspp.54 kernel with the latest beta refresh (1102)? When I try to put that on, it says a newer kernel is already installed, now I can force it, but that made me wonder if we even need the lspp.54 kernel. - Loulwa From eparis at redhat.com Fri Nov 10 20:49:46 2006 From: eparis at redhat.com (Eric Paris) Date: Fri, 10 Nov 2006 15:49:46 -0500 Subject: [redhat-lspp] latest rhel refresh and .54 kernel In-Reply-To: <4554E4B9.5050504@us.ibm.com> References: <4554E4B9.5050504@us.ibm.com> Message-ID: <1163191786.12271.13.camel@localhost.localdomain> On Fri, 2006-11-10 at 14:44 -0600, Loulwa Salem wrote: > Hi, > Do we still need to update the kernel to the lspp.54 kernel with the latest beta > refresh (1102)? > > When I try to put that on, it says a newer kernel is already installed, now I > can force it, but that made me wonder if we even need the lspp.54 kernel. > > - Loulwa Sadly yes, 1102 does not have all the patches in .54. Just wait till later today when steve announces .55 and you won't have any trouble. -Eric From efleury at br.ibm.com Fri Nov 10 21:57:32 2006 From: efleury at br.ibm.com (Eduardo Madeira Fleury) Date: Fri, 10 Nov 2006 19:57:32 -0200 Subject: [redhat-lspp] run_init dying with SIGHUP when called from pexpect as sysadm Message-ID: <200611101957.33005.efleury@br.ibm.com> People, I've been dealing with a strange error. If I try to execute run_init from within pexpect, being sysadm_r:sysadm_t, it dies with SIGHUP signal. If I try the exact same procedure as auditadm_r:auditadm_t it works fine. To reproduce: # python from pexpect import run eve = {'(?i)Password: ' : '\n'} run("/usr/sbin/run_init service", withexitstatus=1, events=eve) I've added a little hack to pexpect so it will "print child.signalstatus" before ending the run method. This way I got the following: Exit: None Sign: 1 (which is SIGHUP) ('Authenticating fleury.\r\nPassword: \r\n', None) It was expected it printed the run_init usage line... It works fine if you try with secadm_r:secadm_t. If nobody manifestates against it I'll open a bug on this. I've tried with RHEL5 10/27 + KickStart v0.9. You are welcome to try this on other configs (the new refresh maybe.. or a system installed w/o KS script). Thanks, -- Eduardo M. Fleury IBM Linux Technology Center Brazil Mobile: +55-19-81224410 email/sametime: fleury at br.ibm.com From sgrubb at redhat.com Fri Nov 10 22:03:02 2006 From: sgrubb at redhat.com (Steve Grubb) Date: Fri, 10 Nov 2006 17:03:02 -0500 Subject: [redhat-lspp] lspp 55 kernel released Message-ID: <200611101703.02794.sgrubb@redhat.com> Hi, The lspp.55 kernel has been published to the lspp yum repo at: http://people.redhat.com/sgrubb/files/lspp The changes are: - Fix cipso oops issues (Paul Moore) - Disallow direct editing of ip option on cipso labeled packets (Paul Moore) - More complete fix for correct getpeercon() results (Venkat Yekkirala) Please let me know if there any problems with this kernel. -Steve From ltcgcw at us.ibm.com Fri Nov 10 23:38:33 2006 From: ltcgcw at us.ibm.com (George C. Wilson) Date: Fri, 10 Nov 2006 17:38:33 -0600 Subject: [redhat-lspp] [Reminder] Open LSPP Development Telecon Mon., Nov. 13 Message-ID: <20061110233833.GA26221@us.ibm.com> IBM hosts a telecon every Monday at 21:00 UTC 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 klaus at atsec.com Sat Nov 11 18:11:50 2006 From: klaus at atsec.com (Klaus Weidner) Date: Sat, 11 Nov 2006 12:11:50 -0600 Subject: [redhat-lspp] RHEL5 10/27 + KS -- Run_init is locking user account In-Reply-To: <200611091528.27562.efleury@br.ibm.com> References: <200611091528.27562.efleury@br.ibm.com> Message-ID: <20061111181150.GA623@w-m-p.com> On Thu, Nov 09, 2006 at 03:28:27PM -0200, Eduardo Madeira Fleury wrote: > Using RHEL5 Server 10/27 refresh installed with the KS script v0.9 I figured > out that executing run_init always increment the pam_tally2 failure count for > the user in question, which means one day or another the user's account gets > locked, currently this happens after 6 successfull run_init calls. [...] > # pam_tally2 --user tux > # run_init service > Type in the correct password, you should see run_init usage string. > # pam_tally2 --user tux > > ... shows 1 failure. And, if you repeat the run_init command 5 or 6 times the > tux account will be locked and then you must unlock it using I can reproduce this using the latest milestone and ks script, and turning off enforcing mode doesn't make a difference (so it's not a permission problem). It looks as if run_init is not executing the "session" PAM path. It's configured in /etc/pam.d/run_init to use the system-auth path which would reset the tally count on successful login, but that never happens. To confirm this, I added the line "session requisite pam_deny.so" as the first "session" rule in /etc/pam.d/run_init, and run_init still executes the session (for example, try "run_init date"). (By contrast, adding "auth requisite pam_deny.so" as the first rule makes run_init always fail the authentication as expected.) I think this qualifies as a bug - when you report it, please include the contents of /etc/pam.d/system-auth and /etc/pam.d/run_init. -Klaus From dwalsh at redhat.com Mon Nov 13 21:08:24 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 13 Nov 2006 16:08:24 -0500 Subject: [redhat-lspp] run_init dying with SIGHUP when called from pexpect as sysadm In-Reply-To: <200611101957.33005.efleury@br.ibm.com> References: <200611101957.33005.efleury@br.ibm.com> Message-ID: <4558DEC8.5030208@redhat.com> Eduardo Madeira Fleury wrote: > People, > > I've been dealing with a strange error. If I try to execute run_init from > within pexpect, being sysadm_r:sysadm_t, it dies with SIGHUP signal. If I try > the exact same procedure as auditadm_r:auditadm_t it works fine. > > To reproduce: > > # python > > from pexpect import run > eve = {'(?i)Password: ' : '\n'} > run("/usr/sbin/run_init service", withexitstatus=1, events=eve) > > I've added a little hack to pexpect so it will "print child.signalstatus" > before ending the run method. This way I got the following: > Exit: None > Sign: 1 (which is SIGHUP) > ('Authenticating fleury.\r\nPassword: \r\n', None) > > It was expected it printed the run_init usage line... It works fine if you try > with secadm_r:secadm_t. > > If nobody manifestates against it I'll open a bug on this. > > I've tried with RHEL5 10/27 + KickStart v0.9. You are welcome to try this on > other configs (the new refresh maybe.. or a system installed w/o KS script). > > Thanks, > AVC Messages. From sds at tycho.nsa.gov Tue Nov 14 00:14:42 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 13 Nov 2006 19:14:42 -0500 Subject: [redhat-lspp] Re: [PATCH] libselinux MLS range context contains for PAM/cron In-Reply-To: <1162936676.26574.15.camel@code.and.org> References: <1162936676.26574.15.camel@code.and.org> Message-ID: <1163463282.24635.99.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2006-11-07 at 16:57 -0500, James Antill wrote: > Here is the libselinux changes needed to do the security context > contains checks for PAM and cron. Thanks, merged. -- Stephen Smalley National Security Agency From klaus at atsec.com Tue Nov 14 00:46:15 2006 From: klaus at atsec.com (Klaus Weidner) Date: Mon, 13 Nov 2006 18:46:15 -0600 Subject: [redhat-lspp] LSPP kickstart config v0.10 released Message-ID: <20061114004615.GC623@w-m-p.com> Hello, an update as promised in today's conf call: Move pam_tally2 config from system-auth to specific entrypoint programs (this should fix the run_init and newrole issues reported) Cups configuration for LSPP mode, from Matt Anderson (Thanks Matt!) Import cups config files from http://free.linux.hp.com/~mra/docs/ add netlabel tools package to default package selection Note that this doesn't automatically add the lspp kernel, please upgrade that manually if you want to test it. The basic features work fine with the default kernel from the beta. RPM download: http://klaus.vh.swiftco.net/lspp/SRPMS/ http://klaus.vh.swiftco.net/lspp/RPMS/noarch/ Git repository: http://klaus.vh.swiftco.net/lspp/git/ -Klaus -- redhat-lspp mailing list redhat-lspp at redhat.com https://www.redhat.com/mailman/listinfo/redhat-lspp From klaus at atsec.com Tue Nov 14 00:46:48 2006 From: klaus at atsec.com (Klaus Weidner) Date: Mon, 13 Nov 2006 18:46:48 -0600 Subject: [redhat-lspp] Re: LSPP kickstart patch In-Reply-To: <20061109215514.GA23358@ldl.lart> References: <20061030222253.GB30812@w-m-p.com> <20061109215514.GA23358@ldl.lart> Message-ID: <20061114004648.GD623@w-m-p.com> On Thu, Nov 09, 2006 at 02:55:14PM -0700, Matt Anderson wrote: > Attached is a patch to the kickstart config which sets up Cups at > install time. The patch contains the changes to cupsd.conf which are > needed, but assumes that lspp-config/lspp has been populated with > client.conf, mime.convs and mime.types from my online documentation: > http://free.linux.hp.com/~mra/docs/ Thanks Matt, I've updated the repository to include the patch and files. -Klaus From cpebenito at tresys.com Tue Nov 14 13:38:03 2006 From: cpebenito at tresys.com (Christopher J. PeBenito) Date: Tue, 14 Nov 2006 08:38:03 -0500 Subject: [redhat-lspp] Re: [PATCH] MLS context contains policy/libselinux changes In-Reply-To: <1162936296.26574.10.camel@code.and.org> References: <1162936296.26574.10.camel@code.and.org> Message-ID: <1163511483.18181.125.camel@sgc.columbia.tresys.com> On Tue, 2006-11-07 at 16:51 -0500, James Antill wrote: > Here is the policy changes needed for the context contains security > checking in PAM and cron. Merged. Added require block to userdomain change since context is a userland object class and thus not automatically required by the gen_require() macro. -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 From efleury at br.ibm.com Tue Nov 14 17:44:21 2006 From: efleury at br.ibm.com (Eduardo Madeira Fleury) Date: Tue, 14 Nov 2006 15:44:21 -0200 Subject: [redhat-lspp] run_init dying with SIGHUP when called from pexpect as sysadm In-Reply-To: <4558DEC8.5030208@redhat.com> References: <200611101957.33005.efleury@br.ibm.com> <4558DEC8.5030208@redhat.com> Message-ID: <200611141544.21970.efleury@br.ibm.com> On Monday 13 November 2006 19:08, Daniel J Walsh wrote: > AVC Messages. > Running in enforcing mode (it fails) I get these records: type=AVC msg=audit(1163511803.779:579): avc: denied { read write } for pid=2324 comm="unix_chkpwd" name="3" dev=devpts ino=5 scontext=staff_u:sysadm_r:system_chkpwd_t:s0-s15:c0.c1023 tcontext=staff_u:object_r:sysadm_devpts_t:s0 tclass=chr_file type=SYSCALL msg=audit(1163511803.779:579): arch=40000003 syscall=11 success=yes exit=0 a0=48e4f8 a1=bf874d5c a2=49cd04 a3=9531948 items=0 ppid=2323 pid=2324 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="unix_chkpwd" exe="/sbin/unix_chkpwd" subj=staff_u:sysadm_r:system_chkpwd_t:s0-s15:c0.c1023 key=(null) type=USER_AUTH msg=audit(1163511803.783:580): user pid=2323 uid=0 auid=500 subj=staff_u:sysadm_r:run_init_t:s0-s15:c0.c1023 msg='PAM: authentication acct=tux : exe="/usr/sbin/run_init" (hostname=?, addr=?, terminal=? res=success)' type=AVC msg=audit(1163511803.787:581): avc: granted { setexec } for pid=2323 comm="run_init" scontext=staff_u:sysadm_r:run_init_t:s0-s15:c0.c1023 tcontext=staff_u:sysadm_r:run_init_t:s0-s15:c0.c1023 tclass=process type=SYSCALL msg=audit(1163511803.787:581): arch=40000003 syscall=4 success=yes exit=43 a0=3 a1=9538db8 a2=2b a3=48afe689 items=0 ppid=2322 pid=2323 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts3 comm="run_init" exe="/usr/sbin/run_init" subj=staff_u:sysadm_r:run_init_t:s0-s15:c0.c1023 key=(null) type=AVC msg=audit(1163511803.787:582): avc: denied { use } for pid=2323 comm="open_init_pty" name="3" dev=devpts ino=5 scontext=system_u:system_r:initrc_t:s0-s15:c0.c1023 tcontext=staff_u:sysadm_r:sysadm_t:s0-s15:c0.c1023 tclass=fd type=AVC msg=audit(1163511803.787:582): avc: denied { use } for pid=2323 comm="open_init_pty" name="3" dev=devpts ino=5 scontext=system_u:system_r:initrc_t:s0-s15:c0.c1023 tcontext=staff_u:sysadm_r:sysadm_t:s0-s15:c0.c1023 tclass=fd type=AVC msg=audit(1163511803.787:582): avc: denied { use } for pid=2323 comm="open_init_pty" name="3" dev=devpts ino=5 scontext=system_u:system_r:initrc_t:s0-s15:c0.c1023 tcontext=staff_u:sysadm_r:sysadm_t:s0-s15:c0.c1023 tclass=fd type=SYSCALL msg=audit(1163511803.787:582): arch=40000003 syscall=11 success=yes exit=0 a0=80491ad a1=bf874fa4 a2=bf874fb0 a3=bf874fa4 items=0 ppid=2322 pid=2323 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="open_init_pty" exe="/usr/sbin/open_init_pty" subj=system_u:system_r:initrc_t:s0-s15:c0.c1023 key=(null) type=AVC_PATH msg=audit(1163511803.787:582): path=2F6465762F7074732F33202864656C6574656429 type=AVC_PATH msg=audit(1163511803.787:582): path=2F6465762F7074732F33202864656C6574656429 type=AVC_PATH msg=audit(1163511803.787:582): path=2F6465762F7074732F33202864656C6574656429 While when running in Permissive (it works) I get these: type=USER_AUTH msg=audit(1163512027.221:593): user pid=2347 uid=0 auid=500 subj=staff_u:sysadm_r:run_init_t:s0-s15:c0.c1023 msg='PAM: authentication acct=tux : exe="/usr/sbin/run_init" (hostname=?, addr=?, terminal=pts/3 res=success)' type=AVC msg=audit(1163512027.221:594): avc: granted { setexec } for pid=2347 comm="run_init" scontext=staff_u:sysadm_r:run_init_t:s0-s15:c0.c1023 tcontext=staff_u:sysadm_r:run_init_t:s0-s15:c0.c1023 tclass=process type=SYSCALL msg=audit(1163512027.221:594): arch=40000003 syscall=4 success=yes exit=43 a0=3 a1=992ffc8 a2=2b a3=48afe689 items=0 ppid=2346 pid=2347 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts3 comm="run_init" exe="/usr/sbin/run_init" subj=staff_u:sysadm_r:run_init_t:s0-s15:c0.c1023 key=(null) type=AVC msg=audit(1163512027.221:595): avc: denied { use } for pid=2347 comm="open_init_pty" name="3" dev=devpts ino=5 scontext=system_u:system_r:initrc_t:s0-s15:c0.c1023 tcontext=staff_u:sysadm_r:sysadm_t:s0-s15:c0.c1023 tclass=fd type=SYSCALL msg=audit(1163512027.221:595): arch=40000003 syscall=11 success=yes exit=0 a0=80491ad a1=bf9f3cb4 a2=bf9f3cc0 a3=bf9f3cb4 items=0 ppid=2346 pid=2347 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts3 comm="open_init_pty" exe="/usr/sbin/open_init_pty" subj=system_u:system_r:initrc_t:s0-s15:c0.c1023 key=(null) type=AVC_PATH msg=audit(1163512027.221:595): path="/dev/pts/3" Regards, -- Eduardo M. Fleury IBM Linux Technology Center Brazil Mobile: +55-19-81224410 email: fleury at br.ibm.com From latten at austin.ibm.com Tue Nov 14 23:55:44 2006 From: latten at austin.ibm.com (Joy Latten) Date: Tue, 14 Nov 2006 17:55:44 -0600 Subject: [redhat-lspp] Toggle for unlabeled packets in labeled ipsec Message-ID: <1163548545.17737.345.camel@faith.austin.ibm.com> I think the ability to toggle whether unlabeled packets will be accepted or rejected for labeled networking is required by lspp. Klaus, is that correct? I noticed that netlabel has this ability via netlabelctl but could not readily find it for labeled ipsec. Would anyone know if we have this ability for labeled ipsec? Regards, Joy From linda.knippers at hp.com Wed Nov 15 00:17:21 2006 From: linda.knippers at hp.com (Linda Knippers) Date: Tue, 14 Nov 2006 19:17:21 -0500 Subject: [redhat-lspp] Toggle for unlabeled packets in labeled ipsec In-Reply-To: <1163548545.17737.345.camel@faith.austin.ibm.com> References: <1163548545.17737.345.camel@faith.austin.ibm.com> Message-ID: <455A5C91.6070102@hp.com> Joy Latten wrote: > I think the ability to toggle whether unlabeled packets > will be accepted or rejected for labeled networking is required by lspp. > Klaus, is that correct? Is it required or does it just need to be audited if you allow it? > > I noticed that netlabel has this ability via netlabelctl but could > not readily find it for labeled ipsec. > Would anyone know if we have this ability for labeled ipsec? I don't know, but it sounds like a handy feature to have. -- ljk > > Regards, > Joy > > -- > redhat-lspp mailing list > redhat-lspp at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-lspp From casey at schaufler-ca.com Wed Nov 15 00:35:49 2006 From: casey at schaufler-ca.com (Casey Schaufler) Date: Tue, 14 Nov 2006 16:35:49 -0800 (PST) Subject: [redhat-lspp] Toggle for unlabeled packets in labeled ipsec In-Reply-To: <1163548545.17737.345.camel@faith.austin.ibm.com> Message-ID: <666933.24357.qm@web36612.mail.mud.yahoo.com> --- Joy Latten wrote: > I think the ability to toggle whether unlabeled > packets > will be accepted or rejected for labeled networking > is required by lspp. > Klaus, is that correct? The behavior of a given packet needs to be deterministic and defined. You don't need to be able to change the behavior on the fly, and if you can you'll be required to describe why that's not a potential violation of your access policy. Or at least, that's what happened in the past. Casey Schaufler casey at schaufler-ca.com From bauerman at br.ibm.com Wed Nov 15 02:19:03 2006 From: bauerman at br.ibm.com (Thiago Jung Bauermann) Date: Wed, 15 Nov 2006 00:19:03 -0200 Subject: [redhat-lspp] mqueue filesystem labeling Message-ID: <1163557143.3930.2.camel@localhost.localdomain> Hi folks, I am having some trouble with POSIX message queues in enforcing mode. I hope someone can shed some light into this... The POSIX message queue implementation uses an internal virtual filesystem called mqueue, so processes wanting to perform operations on POSIX message queues must have access to that filesystem. The problem is that for some reason the mqueue filesystem is labeled at SystemHigh, so only processes at that level are able to create message queues. I don't think this is breaking any functionality, so... do we care? The only line I could find in the SELinux policy about this is: fs_use_trans mqueue gen_context(system_u:object_r:tmpfs_t,s0); The above says that the mqueue fs should be at SystemLow. This is how the kernel initializes it: SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs Even if I explicitly set a SystemLow context for the filesystem when mounting it, it is still mounted as SystemHigh: [root at alex mls]# mount -t mqueue mqueue /mnt [root at alex mls]# ls -Zd /mnt drwxrwxrwt root root system_u:object_r:tmpfs_t:SystemHigh /mnt [root at alex mls]# umount /mnt [root at alex mls]# mount -o fscontext=system_u:object_r:tmpfs_t:s0 -t mqueue mqueue /mnt [root at alex mls]# ls -Zd /mnt drwxrwxrwt root root system_u:object_r:tmpfs_t:SystemHigh /mnt [root at alex mls]# umount /mnt [root at alex mls]# mount -o context=system_u:object_r:tmpfs_t:s0 -t mqueue mqueue /mnt [root at alex mls]# ls -Zd /mnt drwxrwxrwt root root system_u:object_r:tmpfs_t:SystemHigh /mnt And here's the audit record generated when trying to create a message queue in enforcing mode: ---- type=PATH msg=audit(10/31/2006 17:00:00.603:752) : item=0 name=myqueue obj=system_u:object_r:root_t:s0 type=CWD msg=audit(10/31/2006 17:00:00.603:752) : cwd=/tmp/tests type=MQ_OPEN msg=audit(10/31/2006 17:00:00.603:752) : oflag=0xc2 mode=777 mq_flags=0x6d8730 mq_maxmsg=16 mq_msgsize=1 mq_curmsgs=0 type=SYSCALL msg=audit(10/31/2006 17:00:00.603:752) : arch=x86_64 syscall=mq_open success=no exit=-13(Permission denied) a0=2aaaaab1f94d a1=c2 a2=1ff a3=7fffac4d8550 items=1 ppid=2581 pid=2608 auid=ealuser uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 comm=queuetest exe=/tmp/tests/queuetest subj=staff_u:sysadm_r:sysadm_t:s0-s15:c0.c1023 key=(null) ---- I got the above record by adding an audit rule for the mq_open() syscall. I find it odd that it doesn't include an AVC message. I thought every denial record had one... And here's an audit record obtained in permissive mode: ---- type=PATH msg=audit(10/31/2006 17:01:12.307:764) : item=2 name=(null) inode=418 dev=00:0d mode=dir,sticky,777 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:tmpfs_t:s15:c0.c1023 type=PATH msg=audit(10/31/2006 17:01:12.307:764) : item=1 name=(null) inode=12076 dev=00:0d mode=file,755 ouid=root ogid=root rdev=00:00 obj=staff_u:object_r:sysadm_tmpfs_t:s0 type=PATH msg=audit(10/31/2006 17:01:12.307:764) : item=0 name=myqueue obj=system_u:object_r:root_t:s0 type=CWD msg=audit(10/31/2006 17:01:12.307:764) : cwd=/tmp/tests type=MQ_OPEN msg=audit(10/31/2006 17:01:12.307:764) : oflag=0xc2 mode=777 mq_flags=0x6d8730 mq_maxmsg=16 mq_msgsize=1 mq_curmsgs=0 type=SYSCALL msg=audit(10/31/2006 17:01:12.307:764) : arch=x86_64 syscall=mq_open success=yes exit=4 a0=2aaaaab1f94d a1=c2 a2=1 ff a3=7fffac4d8550 items=3 ppid=2581 pid=2608 auid=ealuser uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts0 comm=queuetest exe=/tmp/tests/queuetest subj=staff_u:sysadm_r:sysadm_t:s0-s15:c0.c1023 key=(null) type=AVC msg=audit(10/31/2006 17:01:12.307:764) : avc: denied { add_name } for pid=2608 comm=queuetest name=myqueue scontext= staff_u:sysadm_r:sysadm_t:s0-s15:c0.c1023 tcontext=system_u:object_r:tmpfs_t:s15:c0.c1023 tclass=dir type=AVC msg=audit(10/31/2006 17:01:12.307:764) : avc: denied { write } for pid=2608 comm=queuetest name=/ dev=mqueue ino=418 s context=staff_u:sysadm_r:sysadm_t:s0-s15:c0.c1023 tcontext=system_u:object_r:tmpfs_t:s15:c0.c1023 tclass=dir ---- -- []'s Thiago Jung Bauermann Software Engineer IBM Linux Technology Center From vyekkirala at trustedcs.com Wed Nov 15 15:16:37 2006 From: vyekkirala at trustedcs.com (Venkat Yekkirala) Date: Wed, 15 Nov 2006 09:16:37 -0600 Subject: [redhat-lspp] Toggle for unlabeled packets in labeled ipsec In-Reply-To: <1163548545.17737.345.camel@faith.austin.ibm.com> Message-ID: <000501c708c9$0c2c7f80$cc0a010a@tcssec.com> > I think the ability to toggle whether unlabeled packets > will be accepted or rejected for labeled networking is > required by lspp. If this is required, this is probably best accomplished by a policy rule (dis)allowing such access. Perhaps a policy boolean? > Klaus, is that correct? From latten at austin.ibm.com Wed Nov 15 15:39:03 2006 From: latten at austin.ibm.com (Joy Latten) Date: Wed, 15 Nov 2006 09:39:03 -0600 Subject: [redhat-lspp] IPSec Configuration doc Message-ID: <1163605143.17737.359.camel@faith.austin.ibm.com> Klaus requested some basic steps and info for configuring labeled ipsec. I started and came up with the following which can later be used to assist those new to labeled ipsec and wishing to understand and use it. This is by no means complete. I will fill in and improve in time. Let me know if anything is incorrect or can be improved. Currently, I am unable to successfully configure and run labeled ipsec in enforcing mode on lspp 55 kernel. I'm working on ironing out policy complaints so we can run in enforcing mode. Has anyone else tried this? regards, Joy --------------------------------------------------------------------------------------- Contents: A. Basic IPSec B. Labeled IPSec C. Configuring Labeled IPSec D. Troubleshooting __________________________________________________________________________ Basic Labeled IPsec Configuration ___________________________________________________________________________ You will need to have selinux installed as well as ipsec-tools-0.6.5-6 or later. A basic IPsec configuration consists of ipsec security policy and ipsec security associations. IPsec security policies are stored in the Security Policy Database (SPD) which resides in the kernel. The IPsec policy contains the information on the security services offered to an IP packet. It is indexed by the selectors; source and desination addresses, source and destination ports, and protocol. The SPD is consulted for inbound and outbound processing of IP packets. Thus a traffic stream must have two policy entries. One for inbound and another for outbound. IPSec policy is entered manually by the setkey utility, which is part of the ipsec-tools package. IPsec security associations are stored in the Security Association Database (SAD), which also resides in the kernel. SAs are the agreements established between two communicating entities. They contain the info used to secure the IP packet. SAs are one way. Thus a trafic stream will have two SAs. One for processing inbound packets and another for outbound packets. SAs are created manually by using the setkey utility. The info passed to the setkey utility, such as cryptographic keys, algorithms, etc... must have been agreed upon by local and remote entities before entering. SAs are created dynamically, that is, created when needed, by using an IKE daemon. This daemon is named racoon and can be found in the ipsec-tools package. The racoon daemon uses a configuration file called racoon.conf. The racoon.conf contains info that is used to create ISAKMP SAs and IPSec SAs. ISAKMP SAs are used to establish secure communications between local and remote racoon daemons in which to negotiate IPSec SAs. ______________________________________________________________________ How Labeled IPSec works. _______________________________________________________________________ Labeled IPSec has extended IPSec such that IPSec Security Policy and Security Associations may contain selinux labels. How to add a Label in IPsec. ---------------------------- An IPsec Policy is manually entered using setkey utility. A security context is included in the parameters entered into the policy. For example, spdadd 10.1.13.55 10.1.20.206 any -ctx 1 1 "system_u:object_r:unlabeled_t:s3:c1.c5" -P in ipsec esp/transport//require; spdadd 10.1.20.206 10.1.13.55 any -ctx 1 1 "system_u:object_r:unlabeled_t:s3:c1.c5" -P out ipsec esp/transport//require; Whether you decide to manually or dynamically create SAs, the IPsec policy must be entered manually, first. The kernel does an access check to determine whether the subject/process is allowed to set the security context contained in the policy. *(association:setcontext) Manually created SAs -------------------- If entering Security Associations manually, you will have already determined parameters required between the two communicating hosts. You would enter these paramaters manually using setkey. For example, add 10.1.13.55 10.1.20.206 esp 35590 -m transport -ctx 1 1 "system_u:object_r:unlabeled_t:s0" -E 3des-cbc "06183223c23a21e8b36c566b" -A hmac-md5 "IPSETEST89ABCDEF"; add 10.1.20.206 10.1.13.55 esp 12360 -m transport -ctx 1 1 "system_u:object_r:unlabeled_t:s0" -E 3des-cbc "06183223c23a21e8b36c566b" -A hmac-md5 "IPSETEST89ABCDEF"; Dynamically created SAs ----------------------- Usually the following happens to dynamically establish an SA. An outbound packet is generated via an application, etc... The IP layer checks the SPD for a policy. In labeled networking, if there isn't a policy, the packet is considered "unlabeled". If there is a policy containing a security context, SELinux checks to see if the flow is allowed to access this policy. The flow's security context must "polmatch" to the security context contained in the policy. *(association:polmatch) If it doesn't the packet will be dropped. If it does, the IP layer will next look for an SA. If an SA has not been established yet, the linux kernel sends an ACQUIRE message to all listening key sockets. The racoon daemon will be listening. The ACQUIRE message is used to tell racoon to negotiate and "acquire" an SA. The kernel sends necessary info in the ACQUIRE, like source and destination address. If the policy contained a security context, then the ACQUIRE will include a security context. However, it won't be the same context as the policy. Instead, it will be that of the socket which generated the packet. The kernel will do an access check to see if the process has permissions to set this context in SA that is to be negotiated. *(association:setcontext) If not, the ACQUIRE message is not sent and the packet is dropped. Racoon will perform an access check to see if the security context for the proposed SA "polmatches" to the security context of the ipsec policy. *(association:polmatch) If it doesn't, racoon complains about not being able to find a corresponding policy and negotiations are dropped. Ultimately, this results in no communications on this traffic stream. Once the SA is established, communications can begin for the traffic stream. In Linux, the packet that generated the ACQUIRE message is dropped. Thus you must try the communications again once the SA is established. For example, "ping 10.x.x.x" results in an ACQUIRE message. This ping fails since the packet is dropped. Once the SA is established, another "ping 10.x.x.x" should work. If an SA exists, note this will also be the case for manually created SAs, no ACQUIRE message is sent. Instead, the kernel does an access check. It checks that the flow is permitted to use the SA. *(association:sendto) If not, the packet is dropped. Otherwise, the packet is sent. Note to Joy: More explanantion about how Linux handles SA bundles and templates because there is another check in there. See xfrm_find_bundle() and xfrm_tmpl_resolv(). Also need to add postroute_last() check done in netfiler. Inbound ---------- When a labeled ipsec packet is received, the SPI, Source and Destination addresses are extracted from the packet and used to lookup the SA. An SPI indicates that an SA pair has been established and all "polmatches" as described above have succeeded. Otherwise, the SA would not have been "established". By established I mean accepted into the SAD. Once all ipsec processing has completed, the packet is passed up to the transport layer. A check is done here to ensure the socket has permission to receive data/packets labeled ith the security context from the SA used. *(association:recvfrom) _________________________________________________________________________ Configuring Labeled IPSec __________________________________________________________________________ Basic steps to use: The examples used below are for Machine A, whose ipaddress is 10.1.20.206 and Machine B whose ipaddress is 10.1.13.55. Machine A and Machine B wish to use labeled ipsec to secure all communications between them. All ipsec configuration is done in the sysadm_r role. 1. You must first add policies to the policy database for a particular traffic stream. To do this, add policy to a file and then use setkey to add the contents to the SPD. For example, on Machine A, the file /tmp/setkey.ipsec contains the following policy info: spdadd 10.1.0.206 10.1.13.55 any -ctx 1 1 "system_u:object_r:unlabeled_t:s0:c0" -P out ipsec esp/transport//require; spdadd 10.1.13.55 10.1.0.206 any -ctx 1 1 "system_u:object_r:unlabeled_t:s0:c0" -P in ipsec esp/transport//require; Machine B's file /tmp/setkey.ipsec contains: spdadd 10.1.0.206 10.1.13.55 any -ctx 1 1 "system_u:object_r:unlabeled_t:s0:c0" -P in ipsec esp/transport//require; spdadd 10.1.13.55 10.1.0.206 any -ctx 1 1 "system_u:object_r:unlabeled_t:s0:c0" -P out ipsec esp/transport//require; NOTE: The only thing different on each machine is the direction "-P in|out". NEXT On each machine, run "setkey -f /tmp/setkey.label" to add the policy to the SPD. 2. Now you need to configure racoon. For a simple config, I use pre-shared keys with a very basic racoon configuration. The two files I will use are psk.txt for preshared keys and racoon's basic config file, racoon.conf. For example: I first add the following to /etc/racoon/psk.txt, (please add whatever text you want for your shared secret key. In this example, I used "flibbertigibbet".) 10.1.13.55 flibbertigibbet 10.1.20.206 flibbertigibbet In /etc/racoon/racoon.conf, I pretty much use the defaults. I have the following in my /etc/racoon/racoon.conf: path include "/etc/racoon"; path pre_shared_key "/etc/racoon/psk.txt"; path certificate "/etc/racoon/certs"; sainfo anonymous { pfs_group 2; lifetime time 1 hour ; encryption_algorithm 3des, aes ; authentication_algorithm hmac_sha1 ; compression_algorithm deflate ; } NOTE: EACH IPsec SA racoon establishes will have the parameters contained in sainfo anonymous. NEXT On both Machine A and Machine B, start the racoon daemon. On the command line issue, /usr/sbin/racoon To stop racoon, get its pid: ps -ef | grep racoon and then kill Viewing and removing contents of SAD and SPD. ---------------------------------------------- 1. To view contents of SAD: setkey -D 2. To view contents of SPD: setkey -DP 3. To flush contents of SAD: setkey -F 4. To flush contents of SPD: setkey -FP ___________________________________________________________________________ Troublshooting labeled ipsec __________________________________________________________________________ 1. Racoon logs info to /var/log/messages. 2. Start racoon in foreground and turn on additional debugging: racoon -d [-d] -F The more [-d]s you enter, the more debug info you get. 3. View the /var/log/audit/audit.log file for denied messages. Search on "association". Most labeled ipsec permissions are in the association class. Also search on "comm=setkey" or "comm=racoon" to see if racoon or setkey generated any denied messages. From latten at austin.ibm.com Tue Nov 14 23:46:42 2006 From: latten at austin.ibm.com (Joy Latten) Date: Tue, 14 Nov 2006 17:46:42 -0600 Subject: [redhat-lspp] Labeled IPSec Configuration Doc Message-ID: <1163548002.17737.343.camel@faith.austin.ibm.com> Klaus requested some basic steps and info for configuring labeled ipsec. I started and came up with the following which can later be used to help those new to labeled ipsec and wishing to use it. The following is by no means complete. I will fill in, improve, and add more and make corrections in time. Let me know if anything is incorrect or what can be done to improve. Currently, I am unable to successfully configure and run labeled ipsec in enforcing mode. Working on ironing out policy complaints so I can successfully configure and run in enforcing mode next. Has anyone else tried this? regards, Joy ------------------------------------------------------------------------------------------- __________________________________________________________________________ Contents: A. Basic IPSec B. Labeled IPSec C. Configuring Labeled IPSec D. Troubleshooting __________________________________________________________________________ Basic IPsec __________________________________________________________________________ You will need to have selinux installed as well as ipsec-tools-0.6.5-6 or later. A basic IPsec configuration consists of ipsec security policy and ipsec security associations. IPsec security policies are stored in the Security Policy Database (SPD) which resides in the kernel. The IPsec policy contains the information on the security services offered to an IP packet. It is indexed by the selectors; source and desination addresses, source and destination ports, and protocol. The SPD is consulted for inbound and outbound processing of IP packets. Thus a traffic stream must have two policy entries. One for inbound and another for outbound. IPSec policy is entered manually by the setkey utility, which is part of the ipsec-tools package. IPsec security associations are stored in the Security Association Database (SAD), which also resides in the kernel. SAs are the agreements established between two communicating entities. They contain the info used to secure the IP packet. SAs are one way. Thus a trafic stream will have two SAs. One for processing inbound packets and another for outbound packets. SAs are created manually by using the setkey utility. The info passed to the setkey utility, such as cryptographic keys, algorithms, etc... must have been agreed upon by local and remote entities before entering. SAs are created dynamically, that is, created when needed, by using an IKE daemon. This daemon is named racoon and can be found in the ipsec-tools package. The racoon daemon uses a configuration file called racoon.conf. The racoon.conf contains info that is used to create ISAKMP SAs and IPSec SAs. ISAKMP SAs are NOT stored in the kernel nor used by IP layer. They are only used to establish secure communications between local and remote racoon daemons in which to negotiate IPSec SAs. ______________________________________________________________________ How Labeled IPSec works. _______________________________________________________________________ Labeled IPSec has extended IPSec such that IPSec Security Policy and Security Associations may contain selinux labels. How to add a Label in IPsec. ---------------------------- An IPsec Policy is manually entered using setkey utility. A security context is included in the parameters entered into the policy. For example, spdadd 10.1.13.55 10.1.20.206 any -ctx 1 1 "system_u:object_r:unlabeled_t:s3:c1.c5" -P in ipsec esp/transport//require; spdadd 10.1.20.206 10.1.13.55 any -ctx 1 1 "system_u:object_r:unlabeled_t:s3:c1.c5" -P out ipsec esp/transport//require; Whether you decide to manually or dynamically create SAs, the IPsec policy must be entered manually, first. The kernel does an access check to determine whether the subject/process is allowed to set the security context contained in the policy. *(association:setcontext) Manually created SAs -------------------- If entering Security Associations manually, you will have already determined parameters required between the two communicating hosts. You would enter these paramaters manually using setkey. For example, add 10.1.13.55 10.1.20.206 esp 35590 -m transport -ctx 1 1 "system_u:object_r:unlabeled_t:s0" -E 3des-cbc "06183223c23a21e8b36c566b" -A hmac-md5 "IPSETEST89ABCDEF"; add 10.1.20.206 10.1.13.55 esp 12360 -m transport -ctx 1 1 "system_u:object_r:unlabeled_t:s0" -E 3des-cbc "06183223c23a21e8b36c566b" -A hmac-md5 "IPSETEST89ABCDEF"; Dynamically created SAs ----------------------- Usually the following happens to dynamically establish an SA. An outbound packet is generated via an application, etc... The IP layer checks the SPD for a policy. In labeled networking, if there isn't a policy, the packet is considered "unlabeled". If there is a policy containing a security context, SELinux checks to see if the flow is allowed to access this policy. The flow's security context must "polmatch" to the security context contained in the policy. *(association:polmatch) If it doesn't the packet will be dropped. If it does, the IP layer will next look for an SA. If an SA has not been established yet, the linux kernel sends an ACQUIRE message to all listening key sockets. The racoon daemon will be listening. The ACQUIRE message is used to tell racoon to negotiate and "acquire" an SA. The kernel sends necessary info in the ACQUIRE, like source and destination address. If the policy contained a security context, then the ACQUIRE will include a security context. However, it won't be the same context as the policy. Instead, it will be that of the socket which generated the packet. The kernel will do an access check to see if the process has permissions to set this context in SA that is to be negotiated. *(association:setcontext) If not, the ACQUIRE message is not sent and the packet is dropped. Racoon will perform an access check to see if the security context for the proposed SA "polmatches" to the security context of the ipsec policy. *(association:polmatch) If it doesn't, racoon complains about not being able to find a corresponding policy and negotiations are dropped. Ultimately, this results in no communications on this traffic stream. Once the SA is established, communications can begin for the traffic stream. In Linux, the packet that generated the ACQUIRE message is dropped. Thus you must try the communications again once the SA is established. For example, "ping 10.x.x.x" results in an ACQUIRE message. This ping fails since the packet is dropped. Once the SA is established, another "ping 10.x.x.x" should work. If an SA exists, note this will also be the case for manually created SAs, no ACQUIRE message is sent. Instead, the kernel does an access check. It checks that the flow is permitted to use the SA. *(association:sendto) If not, the packet is dropped. Otherwise, the packet is sent. Note to Joy: More explanantion about how Linux handles SA bundles and templates because there is another check in there. See xfrm_find_bundle() and xfrm_tmpl_resolv(). Also need to add postroute_last() check done in netfiler. Inbound ---------- When a labeled ipsec packet is received, the SPI, Source and Destination addresses are extracted from the packet and used to lookup the SA. An SPI indicates that an SA pair has been established and all "polmatches" as described above have succeeded. Otherwise, the SA would not have been "established". By established I mean accepted into the SAD. Once all ipsec processing has completed, the packet is passed up to the transport layer. A check is done here to ensure the socket has permission to receive data/packets labeled ith the security context from the SA used. *(association:recvfrom) _________________________________________________________________________ Configuring Labeled IPSec __________________________________________________________________________ Basic steps to use: The examples used below are for Machine A, whose ipaddress is 10.1.20.206 and Machine B whose ipaddress is 10.1.13.55. Machine A and Machine B wish to use labeled ipsec to secure all communications between them. Their security policy will contain the security context "system_u:object_r:unlabeled_t:s0:c0" for this example. All ipsec configuration is done in the sysadm_r role. 1. You must first add policies to the policy database for a particular traffic stream. To do this, add policy to a file and then use setkey to add the contents to the SPD. For example, on Machine A, the file /tmp/setkey.ipsec contains the following policy info: spdadd 10.1.0.206 10.1.13.55 any -ctx 1 1 "system_u:object_r:unlabeled_t:s0:c0" -P out ipsec esp/transport//require; spdadd 10.1.13.55 10.1.0.206 any -ctx 1 1 "system_u:object_r:unlabeled_t:s0:c0" -P in ipsec esp/transport//require; Machine B's file /tmp/setkey.ipsec contains: spdadd 10.1.0.206 10.1.13.55 any -ctx 1 1 "system_u:object_r:unlabeled_t:s0:c0" -P in ipsec esp/transport//require; spdadd 10.1.13.55 10.1.0.206 any -ctx 1 1 "system_u:object_r:unlabeled_t:s0:c0" -P out ipsec esp/transport//require; NOTE: The only thing different on each machine is the direction "-P in|out". NEXT On each machine, run "setkey -f /tmp/setkey.label" to add the policy to the SPD. 2. Now you need to configure racoon. For a simple config, I use pre-shared keys with a very basic racoon configuration. The two files I will use are psk.txt for preshared keys and racoon's basic config file, racoon.conf. For example: I first add the following to /etc/racoon/psk.txt, (please add whatever text you want for your shared secret key. In this example, I used "flibbertigibbet".) 10.1.13.55 flibbertigibbet 10.1.20.206 flibbertigibbet In /etc/racoon/racoon.conf, I pretty much use the defaults. I have the following in my /etc/racoon/racoon.conf: path include "/etc/racoon"; path pre_shared_key "/etc/racoon/psk.txt"; path certificate "/etc/racoon/certs"; sainfo anonymous { pfs_group 2; lifetime time 1 hour ; encryption_algorithm 3des, aes ; authentication_algorithm hmac_sha1 ; compression_algorithm deflate ; } NOTE: EACH IPsec SA that racoon establishes will have the parameters contained in sainfo anonymous. NEXT On both Machine A and Machine B, start the racoon daemon. On the command line issue, /usr/sbin/racoon To stop racoon, get its pid: ps -ef | grep racoon and then kill NEXT Run a networking command such as ping or nc to send a packet from Machine A to Machine B. It will fail at first. Wait a few seconds. Now try again. If SAs were successfully established, it should work. Viewing and removing contents of SAD and SPD. ---------------------------------------------- 1. To view contents of SAD: setkey -D 2. To view contents of SPD: setkey -DP 3. To flush contents of SAD: setkey -F 4. To flush contents of SPD: setkey -FP Troublshooting Labeled IPsec ----------------------------- 1. Racoon logs info to /var/log/messages. 2. Start racoon in foreground and turn on additional debugging: racoon -d [-d] -F The more [-d]s you enter, the more debug info you get. 3. View the /var/log/audit/audit.log file for denied messages. Search on "association". Most labeled ipsec permissions are in the association class. Also search on "comm=setkey" or "comm=racoon" to see if racoon or setkey generated any denied messages. From gcwilson at us.ibm.com Wed Nov 15 18:51:08 2006 From: gcwilson at us.ibm.com (George Wilson) Date: Wed, 15 Nov 2006 12:51:08 -0600 Subject: [redhat-lspp] mqueue filesystem labeling In-Reply-To: <1163557143.3930.2.camel@localhost.localdomain> Message-ID: redhat-lspp-bounces at redhat.com wrote on 11/14/2006 20:19:03: > Hi folks, > > I am having some trouble with POSIX message queues in enforcing mode. I > hope someone can shed some light into this... > > The POSIX message queue implementation uses an internal virtual > filesystem called mqueue, so processes wanting to perform operations on > POSIX message queues must have access to that filesystem. > > The problem is that for some reason the mqueue filesystem is labeled at > SystemHigh, so only processes at that level are able to create message > queues. This is strange. > > I don't think this is breaking any functionality, so... do we care? Good question. I don't know what's using POSIX MQs. > > > > The only line I could find in the SELinux policy about this is: > > fs_use_trans mqueue gen_context(system_u:object_r:tmpfs_t,s0); > > The above says that the mqueue fs should be at SystemLow. > This is how the kernel initializes it: > > SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs > > Even if I explicitly set a SystemLow context for the filesystem when > mounting it, it is still mounted as SystemHigh: > > [root at alex mls]# mount -t mqueue mqueue /mnt > [root at alex mls]# ls -Zd /mnt > drwxrwxrwt root root system_u:object_r:tmpfs_t:SystemHigh /mnt > [root at alex mls]# umount /mnt > > [root at alex mls]# mount -o fscontext=system_u:object_r:tmpfs_t:s0 -t > mqueue mqueue /mnt > [root at alex mls]# ls -Zd /mnt > drwxrwxrwt root root system_u:object_r:tmpfs_t:SystemHigh /mnt > [root at alex mls]# umount /mnt > > [root at alex mls]# mount -o context=system_u:object_r:tmpfs_t:s0 -t mqueue > mqueue /mnt > [root at alex mls]# ls -Zd /mnt > drwxrwxrwt root root system_u:object_r:tmpfs_t:SystemHigh /mnt > > > > And here's the audit record generated when trying to create a message > queue in enforcing mode: > > ---- > type=PATH msg=audit(10/31/2006 17:00:00.603:752) : item=0 name=myqueue > obj=system_u:object_r:root_t:s0 > type=CWD msg=audit(10/31/2006 17:00:00.603:752) : cwd=/tmp/tests > > type=MQ_OPEN msg=audit(10/31/2006 17:00:00.603:752) : > oflag=0xc2 mode=777 mq_flags=0x6d8730 mq_maxmsg=16 mq_msgsize=1 > mq_curmsgs=0 > > type=SYSCALL msg=audit(10/31/2006 17:00:00.603:752) : arch=x86_64 > syscall=mq_open success=no exit=-13(Permission denied) a0=2aaaaab1f94d > a1=c2 a2=1ff a3=7fffac4d8550 items=1 ppid=2581 pid=2608 auid=ealuser > uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root > fsgid=root tty=pts0 comm=queuetest exe=/tmp/tests/queuetest > subj=staff_u:sysadm_r:sysadm_t:s0-s15:c0.c1023 key=(null) > ---- > > I got the above record by adding an audit rule for the mq_open() > syscall. I find it odd that it doesn't include an AVC message. I thought > every denial record had one... > > And here's an audit record obtained in permissive mode: > > ---- > type=PATH msg=audit(10/31/2006 17:01:12.307:764) : item=2 name=(null) > inode=418 dev=00:0d mode=dir,sticky,777 ouid=root ogid=root rdev=00:00 > obj=system_u:object_r:tmpfs_t:s15:c0.c1023 > > type=PATH msg=audit(10/31/2006 17:01:12.307:764) : item=1 name=(null) > inode=12076 dev=00:0d mode=file,755 ouid=root ogid=root rdev=00:00 > obj=staff_u:object_r:sysadm_tmpfs_t:s0 > > type=PATH msg=audit(10/31/2006 17:01:12.307:764) : item=0 name=myqueue > obj=system_u:object_r:root_t:s0 > > type=CWD msg=audit(10/31/2006 17:01:12.307:764) : > cwd=/tmp/tests > > type=MQ_OPEN msg=audit(10/31/2006 17:01:12.307:764) : oflag=0xc2 > mode=777 mq_flags=0x6d8730 mq_maxmsg=16 mq_msgsize=1 mq_curmsgs=0 > > type=SYSCALL msg=audit(10/31/2006 17:01:12.307:764) : arch=x86_64 > syscall=mq_open success=yes exit=4 a0=2aaaaab1f94d a1=c2 a2=1 > ff a3=7fffac4d8550 items=3 ppid=2581 pid=2608 auid=ealuser uid=root > gid=root euid=root suid=root fsuid=root egid=root sgid=root > fsgid=root tty=pts0 comm=queuetest exe=/tmp/tests/queuetest > subj=staff_u:sysadm_r:sysadm_t:s0-s15:c0.c1023 key=(null) > > type=AVC msg=audit(10/31/2006 17:01:12.307:764) : avc: denied > { add_name } for pid=2608 comm=queuetest name=myqueue scontext= > staff_u:sysadm_r:sysadm_t:s0-s15:c0.c1023 > tcontext=system_u:object_r:tmpfs_t:s15:c0.c1023 tclass=dir > > type=AVC msg=audit(10/31/2006 17:01:12.307:764) : avc: denied > { write } for pid=2608 comm=queuetest name=/ dev=mqueue ino=418 s > context=staff_u:sysadm_r:sysadm_t:s0-s15:c0.c1023 > tcontext=system_u:object_r:tmpfs_t:s15:c0.c1023 tclass=dir > ---- > So it is being controlled by add_name(). But it should be controlled directly in mq_open(). We would need a new LSM hook in mq_open(), and policy to handle it. Perhaps we can document this as a special case of control not being enforced by an open if we have to. Thanks, George Wilson IBM LTC Security Development -------------- next part -------------- An HTML attachment was scrubbed... URL: From latten at austin.ibm.com Wed Nov 15 18:47:28 2006 From: latten at austin.ibm.com (Joy Latten) Date: Wed, 15 Nov 2006 12:47:28 -0600 Subject: [redhat-lspp] anyway to reverse a dontaudit rule? Message-ID: <1163616448.17737.368.camel@faith.austin.ibm.com> Is there a way to reverse a dontaudit rule without having to modify and recompile base policy? I need to see the audit message to help determine what permissions are being denied for a particular application. Regards, Joy From mra at hp.com Wed Nov 15 22:01:00 2006 From: mra at hp.com (Matt Anderson) Date: Wed, 15 Nov 2006 17:01:00 -0500 Subject: Fwd: Re: [redhat-lspp] CUPS w/ Matt's config in RHEL5 not printing? In-Reply-To: <200611061738.25583.efleury@br.ibm.com> References: <200611061738.25583.efleury@br.ibm.com> Message-ID: <455B8E1C.5090201@hp.com> Eduardo Madeira Fleury wrote: > On Monday 06 November 2006 17:09, you wrote: >> You should still be getting the SELinux deny on the printer since the >> needed constraint wasn't in the policy. I got an update on my bugzilla >> and the constraint will be included starting with the selinux policy >> 2.4.3-1 rpm. > > Thanks, so that's a matter of waiting for another refresh. I still need to look through the updated cups policy. In my testing on selinux-policy-mls 2.4.3-13 I'm still not seeing the behavior I'm expecting so I need to look at the source and put a patch together to send to Dan Walsh. >> As for the usb://Lexmark/T630 URI printers without /dev/ in their URI >> are not checked for file system permissions before the job is sent. >> Your admin guide should specify that printers MUST be created with the >> /dev/usb/lp* style URI. > > Yes, I remember that discussion, actually I used the Manufacturer/Model URI > only to try to isolate the problem. I dug deeper into this, it seems that the usb backend is eventually failing because it is running into DAC permission failure when trying to access the printer. By changing the "Group sys" line in /etc/cups/cupsd.conf to "Group lp" the usb backend will no longer get permission denied. >> From the error you are seeing it sounds like the pstops filter is having >> trouble with your postscript document. If you revert the config files >> to their defaults do you still see that problem? > > No, if I revert the config files the printer works fine. Actually, reversing > only mime.convs and mime.types is enough for it to work, and banner pages are > printed fine also. This is because the LSPP mime.* files make use of pstopdf as a filter, which requires ghostscript in order to run. Including ghostscript in the LSPP kickstart install will eliminate this problem. Klaus: if you could make the following changes I this issue will be resolved: 1) In lspp-config/bin/lspp-eal4-config.in around line 218 change < aGroup sys --- > aGroup lp 2) Add the package ghostscript to packages-common.cfg -matt From kmacmillan at mentalrootkit.com Wed Nov 15 22:06:49 2006 From: kmacmillan at mentalrootkit.com (Karl MacMillan) Date: Wed, 15 Nov 2006 17:06:49 -0500 Subject: [redhat-lspp] Re: anyway to reverse a dontaudit rule? In-Reply-To: <1163616448.17737.368.camel@faith.austin.ibm.com> References: <1163616448.17737.368.camel@faith.austin.ibm.com> Message-ID: <455B8F79.4020504@mentalrootkit.com> Joy Latten wrote: > Is there a way to reverse a dontaudit rule without having to > modify and recompile base policy? > I need to see the audit message to help determine what permissions > are being denied for a particular application. > No - that is why the enableaudit.pp base policy is provided in /usr/share/selinux/[policyname]/enableaudit.pp. Install that with: semodule -b path_to_enableaudit and you should see all denials. Karl From drepper at redhat.com Thu Nov 16 05:44:32 2006 From: drepper at redhat.com (Ulrich Drepper) Date: Wed, 15 Nov 2006 21:44:32 -0800 Subject: [redhat-lspp] mqueue filesystem labeling In-Reply-To: References: Message-ID: <455BFAC0.6070907@redhat.com> George Wilson wrote: > > I don't think this is breaking any functionality, so... do we care? > > Good question. I don't know what's using POSIX MQs. POSIX message queues are a general mechanism, every program can use them. They are much faster than the SysV message queues. The filesystem is mainly used to clean up. Message queues can have names and they stay around, unless removed, if the processes using them are going away. Not everybody should have permission to do everything on the filesystem but message queues have owners and those owners must be able to remove them. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? From twaugh at redhat.com Thu Nov 16 10:00:41 2006 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 16 Nov 2006 10:00:41 +0000 Subject: Fwd: Re: [redhat-lspp] CUPS w/ Matt's config in RHEL5 not printing? In-Reply-To: <455B8E1C.5090201@hp.com> References: <200611061738.25583.efleury@br.ibm.com> <455B8E1C.5090201@hp.com> Message-ID: <1163671241.4196.14.camel@cyberelk.elk> On Wed, 2006-11-15 at 17:01 -0500, Matt Anderson wrote: > I dug deeper into this, it seems that the usb backend is eventually > failing because it is running into DAC permission failure when trying to > access the printer. By changing the "Group sys" line in > /etc/cups/cupsd.conf to "Group lp" the usb backend will no longer get > permission denied. You should find that taking out that 'Group' line altogether fixes the problem as well. Why did 'Group sys' end up in the cupsd.conf file? Could it be that some KDE tool put it in there (I have a vague recollection that it does..)? Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bauerman at br.ibm.com Thu Nov 16 12:56:12 2006 From: bauerman at br.ibm.com (Thiago Jung Bauermann) Date: Thu, 16 Nov 2006 10:56:12 -0200 Subject: [redhat-lspp] mqueue filesystem labeling In-Reply-To: <455BFAC0.6070907@redhat.com> References: <455BFAC0.6070907@redhat.com> Message-ID: <1163681772.7192.6.camel@localhost.localdomain> On Wed, 2006-11-15 at 21:44 -0800, Ulrich Drepper wrote: > George Wilson wrote: > > > I don't think this is breaking any functionality, so... do we care? > > > > Good question. I don't know what's using POSIX MQs. > > POSIX message queues are a general mechanism, every program can use > them. They are much faster than the SysV message queues. Good to know the advantage of POSIX mq over SysV mq. I was wondering about this. :-) > The filesystem is mainly used to clean up. Message queues can have > names and they stay around, unless removed, if the processes using them > are going away. Not everybody should have permission to do everything > on the filesystem but message queues have owners and those owners must > be able to remove them. The problem I'm seeing happens even when using mq_open(3) to create a new message queue, without mounting or explicitly using the mqueue filesystem. -- []'s Thiago Jung Bauermann Software Engineer IBM Linux Technology Center From cpebenito at tresys.com Thu Nov 16 14:05:46 2006 From: cpebenito at tresys.com (Christopher J. PeBenito) Date: Thu, 16 Nov 2006 09:05:46 -0500 Subject: [redhat-lspp] Re: anyway to reverse a dontaudit rule? In-Reply-To: <455B8F79.4020504@mentalrootkit.com> References: <1163616448.17737.368.camel@faith.austin.ibm.com> <455B8F79.4020504@mentalrootkit.com> Message-ID: <1163685946.7374.32.camel@sgc.columbia.tresys.com> On Wed, 2006-11-15 at 17:06 -0500, Karl MacMillan wrote: > Joy Latten wrote: > > Is there a way to reverse a dontaudit rule without having to > > modify and recompile base policy? > > I need to see the audit message to help determine what permissions > > are being denied for a particular application. > > > > No - that is why the enableaudit.pp base policy is provided in > /usr/share/selinux/[policyname]/enableaudit.pp. Install that with: > > semodule -b path_to_enableaudit > > and you should see all denials. Yes. Eventually all of the dontaudits will be made conditional, controlled by a Boolean. -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 From mra at hp.com Thu Nov 16 16:37:42 2006 From: mra at hp.com (Matt Anderson) Date: Thu, 16 Nov 2006 11:37:42 -0500 Subject: Fwd: Re: [redhat-lspp] CUPS w/ Matt's config in RHEL5 not printing? In-Reply-To: <1163671241.4196.14.camel@cyberelk.elk> References: <200611061738.25583.efleury@br.ibm.com> <455B8E1C.5090201@hp.com> <1163671241.4196.14.camel@cyberelk.elk> Message-ID: <455C93D6.3040703@hp.com> Tim Waugh wrote: > On Wed, 2006-11-15 at 17:01 -0500, Matt Anderson wrote: >> I dug deeper into this, it seems that the usb backend is eventually >> failing because it is running into DAC permission failure when trying to >> access the printer. By changing the "Group sys" line in >> /etc/cups/cupsd.conf to "Group lp" the usb backend will no longer get >> permission denied. > > You should find that taking out that 'Group' line altogether fixes the > problem as well. Why did 'Group sys' end up in the cupsd.conf file? > Could it be that some KDE tool put it in there (I have a vague > recollection that it does..)? The line was added during the evaluated configuration post-install. We have a sed script which runs over /etc/cups/cupsd.conf setting: Browsing off Classification mls ClassifyOverride no RunAsUser Yes User lp Group lp and also disabling listening on localhost:631 This disables administrating the system over the web interface which we need because of the limited authentication/auditing which can take place there. If you are aware of any other possible issues we may face with this configuration please let us know. -matt From twaugh at redhat.com Thu Nov 16 16:55:13 2006 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 16 Nov 2006 16:55:13 +0000 Subject: Fwd: Re: [redhat-lspp] CUPS w/ Matt's config in RHEL5 not printing? In-Reply-To: <455C93D6.3040703@hp.com> References: <200611061738.25583.efleury@br.ibm.com> <455B8E1C.5090201@hp.com> <1163671241.4196.14.camel@cyberelk.elk> <455C93D6.3040703@hp.com> Message-ID: <1163696113.4943.9.camel@cyberelk.elk> On Thu, 2006-11-16 at 11:37 -0500, Matt Anderson wrote: > RunAsUser Yes This option no longer exists in CUPS-1.2.x. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From loulwas at us.ibm.com Thu Nov 16 17:16:34 2006 From: loulwas at us.ibm.com (Loulwa Salem) Date: Thu, 16 Nov 2006 11:16:34 -0600 Subject: [redhat-lspp] LSPP Development Telecon 11/13/2006 Minutes Message-ID: <455C9CF2.80708@us.ibm.com> HI, Sorry for the delay .. been very busy 11/13/2006 lspp Meeting Minutes: =============================== Attendees George Wilson (IBM) - GW Loulwa Salem (IBM) - LS Michael Thompson (IBM) - MT Joy Latten (IBM) - JL Steve Grubb (Red Hat) - SG Eric Paris (Red Hat) - EP Dan Walsh (Red Hat) - DW James Antill (Red Hat) - JA Lisa Smith (HP) - LMS Linda Knippers (HP) - LK Amy Griffis (HP) - AG Matt Anderson (HP) - MA Paul Moore (HP) - PM Klaus Weidner (Atsec) - KW Tentative Agenda: MA: Klaus, did you see my patch for your kickstart scrip? I sent it to mailing list and copied you I think. KW: didn't see that yet, I'll check it and email you GW: I hacked on my self tests Matt. I am not getting back what I think I'll get for the python bindings. do you know much about that? MA: not much .. no GW: the methods are not really behaving as I expected. Apologies for the mess with the call in number. It was the previous project manager's number and I didn't transfer it to my name. We'll wait a bit for RedHat people to join. Kernel update ------------- GW: So are people having good luck with the .55 and latest beta. LS: It seems fine to me I have it running on two systems. Do we need to resolve the issue regarding the kernel panic on first boot, and having to boot the first time in enforcing. GW: I think that it is due to the kickstart, things got out of sync somehow. PM: we haven't seen that, but we have not been testing with lspp kernels GW: I also saw an issue with initrd and LVM. it couldn't find my root system. PM: we'll keep our eyes open if we see it here GW: maybe if we do a new fresh install we won't see the problem again LS: I did a new install with the 1102 beta, and still saw the problem KW: I installed this weekend and that worked fine. Try it again and if you see any problems let me know because that shouldn't happen GW: someone overwrote the versions I had.. so I'll try that again PM: I've seen a problem when auditd was not started on a first boot, and it would hang until there is a command entered. KW: maybe related to activity on /dev/random SG: auditd doesn't even touch /dev/random PM: it seems the machine doesn't start up all the way, and you'd have to go to lab and give some keywords and it continues booting. SG: go into init script and tell it to do an strace. maybe that will give us some clues PM: not necessarily clear it is auditd, it is waiting for ok before it starts SG: see the strace to see if it makes it through the daemon. PM: the tricky part is that it is only on the first boot. we've only seen it on ia64 GW: I have seen another problem where console does not show a login prompt, but it's fine to ssh MA: I was seeing that, but if I press "enter" I would get one. GW: I was not getting anything even with pressing "enter". so that was the other first boot problem, maybe an artifact of the kickstart process. I'll look for AVC and come up with reason why that is happening. Beta / Rawhide update --------------------- GW: any other issues with beta. other than the fist boot issues. I had good luck so far with the installs. SELinux base update ------------------- GW: ant selinux issues Dan? DW: A big controversial one is sysadm being able to read audit logs at systemHigh. there is bugzilla where I say I don't think we should fix this. first, it is alot of changes in the policy, second, we are not buying our selves any security if we do that, so I am apprehensive. Right now sysadm has privilege to read/write all file types. I attempted to change the type of audit files so that it is not writable by sysadm, but that caused problems, so I reversed it. I thought about it and we really can't protect those files from sysadm. The reason we wanted to separate auditadm and sysadm is to prevent accidental changes. but sysadm needs to be systemHigh and if he does that then that is a malicious user MT: now that I heard explanation, it's fine from my perspective. if it is fine from lspp cert point of view, then I'll say let's close it GW: it is fine from lspp certification point of view. DW: sysadm is very powerful as well as secadm. as we move with rbac, we'll break it into smaller roles. If someone is sysadm, they have a lot of privileges anyway, it is difficult to stop sysadm from doing anything GW: it is nice to have, but we don't want to drastically change anything at this point. KW: from cert point of view, it is not important. lspp profile is not specific about roles on system; I think it is ok that sysadm is powerful role and reads audit log. it'll be nice to keep admins from accidentally changing the system, but if they want to do that, then there is no way to change that DW: I don't see where we will be running sysadm at SystemHigh anyway KW: yup .. it's ok GW: so you'll close the bug MT: yes DW: there are many policy changes going on KW: I posted to the list about this, there are unclear things in mls constraints. so far I have not seen justifications, they may be some cut/paste errors. unless someone speaks up about why they need to be there, we need to change that DW: waiting for TCS to comment on that KW: looks to me like cut/paste errors which happen to work if you are at equal levels. I can work out a patch to fix this if we don't hear from them GW: do you have bug open KW: I hadn't done that. but I'll open one MA: Dan I might have policy updates for the usb cups. It has something to do with bi-directionality with usb printer. DW: also was looking at init problem.. pam tally logs on an authenticate, but goes down on session. I don't think run init uses session SG: need to see how we can fix it DW: I can fix run init to use session SG: session has ability to mount. there is no pam module that does those actions. session start/close with pam-tally KW: at the moment I have it configured to use pam_tally in system_auth file which is used by everything DW: looks like ... SG: one thing is that in rhel4 we put pam-tally in each service at the entry point. I want to think it was on case by case bases KW: if it is a problem, I can put it on individual entry points of data. I am assuming that run init .. DW: not sure why they didn't do pam session. we'll keep this one online now, no reason why not to do session for those programs LK: is there bugzilla for this? DW: no LK: should there be? DW: yes, so klaus will you add bugzilla KW: yes .. I checked previous evaluation, and there was pam_tally in auth file MLS policy issues ------------------ GW: any other pol type things? PAM, Newrole & VFS polyinstantiation ------------------------------------ GW: have not played with level selection path since last week. verified I am hitting pam problems which is making it behave strangely. I'll reinstall this evening and rebuild patches see how it looks. I'd like to get klaus to take a look at that. KW: ok .. yeah GW: what about newrole patch MT: little activity last week, nothing major, mainly trying to get grasp on patches. it's been third send for this patch set. no major negative comments. in latest send, there has been no negative comments, i guess that is a good thing. I'm sitting on it, don't know how to proceed from this point, when would I send it, also we are getting close to holidays. if anyone has advice on what would be good way to proceed. DW: did you get ack from stephen? MT: has not seen any ack, though this is third send .. DW: I'd just send him a note MT: alright, I'll do that GW: has anyone else had problems with pollyinstantiation? MT: newrole packages in the policycoreutils_newrole, is that the same previous one DW: yes, just spec file changes MT: non uid 0 cannot execute newrole. I have not tried this, but people who tried that in enforcing/permissive mode, you cannot authenticate correctly if you are not root GW: current beta? MT: yes, with kickstart install DW: what's happening is you are not able to read shadow file. pam gets confused and thinks you should be able to. it should work like selinux in enforcing mode. you are basically getting permission denied KW: just tried it, in /var/log/secure there is message SG: maybe labeling problem KW: this is in non enforcing mode MT: wasn't seeing avc messages DW: probably the last raw in config file .. so I'll change config to use pam_tally only for the entry point rather than all other services KW: if you used kickstart, then you are using /var/log/tally.log GW: is this new to this kernel MT: yes ... it was getting denied so authentication fails KW: keep in mind newrole is not suid, and it doesn't have perms to write to tally.log MT: it is suid on system I just installed in case you need to address that KW: I'll check on that. MT: newrole only deals with caller's password and if audit is enabled, it checks the auid KW: ok, I'll change that and send out a new script GW: any other issues with pam and authentication .. KW: So, I won't open bug for the init, since I'll fix that with putting pam_tally at entry points. GW: sounds like a good way to fix it. anything else? Audit ------ GW: anything new on audit SG: no Print ------ MA: I ended up finding problem that eduardo is running into. it is that pspdf is not running. once you install ghostscript that fixes the problem. LK: is that in kickstart script patch you sent to klaus MA: I'll have to send that to him. also I found that printer is not getting connected. maybe selinux policy issue. LK: does it work in permissive mode MA: no. but this is on kickstart installed mode.so maybe a missing package. I am looking into that usb interface is working correctly. one good thing /dev/usb0 uri and the hp/lexmark uri both have same error. the benefit of that is we'll use fs to do the limit on the uri. not looking for something specific to vendor/model uri. another thing, looking into way to setup printers in through the lp admin program. if there was some RH specific things we would need to make sure we capture and document those. I'll check that we are not dropping something RH specific. GW: great MA: has anyone tried the network config .. it seems like it is missing some dependencies GW: we need to revisit the package list and check MA: I'll look more into that and send out a not about missing pack CIPSO ------ PM: there was some issue last week, but we resolved that. all my testing so far looks pretty good. I ran through network relevant test in LTP. it looks like we are in pretty good shape. SG: one thing that came up last week, while reviewing joy's patch for ipsec. I forgot to look at your patch to see what would your patch do if audit is disabled. if audit is disabled, there should not be any audit message. I forgot to look at that in your patch. if it produces something, we need another patch to prevent audit logs PM: should that be handled in the audit subsystem SG: programs skip all the setup work. if audit system is disabled it shouldn't need to go through the work. GW: should we expect another patch PM: I'll try that, look at the code and send something. if I do send patch, it'll be really small SG: sounds about right, probably 2 lines of code at the entry points for audit log. I think there was an inline static function that did the check. GW: joy, how did your audit patches go for ipsec JL: so far so good. I sent them friday. I have the .55 kernel. so I'll run some stress tests. fernando and I are going through setting up ipsec without enforcing mode. the rules we are encountering we'll send out to the list SG: I'll take a look at the audit patch and I'll send you the feedback JL: thanks. that's all, saw the venkat did additional patches, and wanted us to try against 2.6.19. should I test the lspp.55 or get the 2.6.19 and put patches on it and test with that GW: get src.rpm of .55 kernel, patch it and test JL: ok, I'll do that. are there any of venkat's patches in .55 kernel EP: which patches ... JL: venkat had set of 3 patches EP: 55 has all three patches GW: do we expect more patches from venkat EP: I don't know of any. I am expecting the 3 config change patches JL: I saw klaus's mail about policy. maybe I want to get those cleared up before we get the ipsec policy. KW: start on testing and see what current behavior is. GW: so you'll be writing policy and doing stress test. when do you expect to have policy updates. JL: I'll try to get it done in next 3 days. we're just seeing alot of denied messages in enforcing. so it is best to iron it out. GW: any other networking issues PM: steve, got xinetd fixed yet? SG: no LK: eta SG: I'll try to get to it soon. still got lots of things in queue. I'll try to get to it this week. IPsec ------ Labeled networking stabilization -------------------------------- xinetd ------- Self tests ----------- GW: I hacked on that a bit, but steve, I did not find the python bindings to work as I had expected SG: ... GW: when I get status, what do I expect SG: you'll get structure from the c code. three or 4 things in there are interesting GW: should I instantiate an object and use attributes from that object SG: I really don't know enough about python to tell you, Dan? DW: you called the audit status? I'll try it now .. GW: so how do I access the members? DW: I tried it and it's broken .. I'll see if I can fix it. it should return a list SG: if you do auditctl -f you'll get something similar to that in a structure form GW: looking at man page, it is not clear how to use that .. man page maybe broken as well SG: ok, it's a two part call, you request the status, then you have to do a get_reply, then you pass that a structure and it should be populated there? GW: ok, that makes sense. SG: it returns to you a sequence number, you don't need to do anything with that seq number, but next thing to do is get_reply GW: that fetches info and puts it in buffer .. SG: yes, audit_get_reply function GW: so I need to do something analogous in python and expect a thing out of that. SG: I think it should spell out that you need to get audit_get_reply in there. GW: I'll send a patch to that SG: I am slowly working toward audit.2.10 intended to go in rc1 GW: As for aide, I have not worked with policy. when I install I'll try that Cron, tmpwatch, mail, etc. --------------------------- GW: is cron working as expected now .. JA: last half of week, they found really small changes GW: ok, we should all be testing on that. have you tried it with having send admin mail JA: no GW: it's something we need to test and no one did that I think JA: ok, so this is not mls changing problem GW: shouldn't be, it's a wrapper around mail program. we decided it was very useful and expected. alright.. any general issues .. ok, everyone write bugs, please bring up on list and let's just keep it up. Is there preference to have meeting next week? ok, we'll tentatively have a meeting next week then. SG: there are few things to get out of agenda .. GW: like audit SG: yeah .. I think we can shorten it up. GW: maybe reordering of the agenda as well SG: cups also ... PM: nothing going on there GW: maybe, we'll have a list of development items and some bugs section. SG: everything that is done and bugs only, let's have that in bugs section. everything that is still open and has development we'll keep that open GW: should this meeting turn into bug tracking meeting? SG: sounds like it's time to do that LK: looks like it is happening that way already .. Bugs / remaining tasks ---------------------- Final cutoff date ------------------ From paul.moore at hp.com Thu Nov 16 19:56:37 2006 From: paul.moore at hp.com (Paul Moore) Date: Thu, 16 Nov 2006 14:56:37 -0500 Subject: [redhat-lspp] IPSec Configuration doc In-Reply-To: <1163605143.17737.359.camel@faith.austin.ibm.com> References: <1163605143.17737.359.camel@faith.austin.ibm.com> Message-ID: <455CC275.1060100@hp.com> Joy Latten wrote: > Klaus requested some basic steps and info for > configuring labeled ipsec. I started and came up with > the following which can later be used to assist those > new to labeled ipsec and wishing to understand and use it. > This is by no means complete. I will fill in and improve > in time. Let me know if anything is incorrect or can be improved. > > Currently, I am unable to successfully configure and run labeled > ipsec in enforcing mode on lspp 55 kernel. I'm working on ironing out > policy complaints so we can run in enforcing mode. Has anyone else > tried this? Thanks for sending this out. Based on your instructions I'm trying to setup a simple, manually keyed labeled IPsec connection between two machines running the lspp.55 kernel; both are using the MLS policy in permissive mode. Unfortunately, I can't seem to get it to work; I assume I am doing something wrong but it is not obvious to me ... * IP addresses - sifl: 10.0.0.1 - olly: 10.0.0.2 * setkey commands - sifl spdadd 10.0.0.1 10.0.0.2 any -ctx 1 1 "system_u:object_r:unlabeled_t:s3:c1.c5" -P out ipsec esp/transport//require; spdadd 10.0.0.2 10.0.0.1 any -ctx 1 1 "system_u:object_r:unlabeled_t:s3:c1.c5" -P in ipsec esp/transport//require; add 10.0.0.1 10.0.0.2 esp 84001 -m transport -ctx 1 1 "system_u:object_r:unlabeled_t:s3:c1.c5" -E 3des-cbc "06183223c23a21e8b36c566b" -A hmac-md5 "IPSETEST89ABCDEF"; add 10.0.0.2 10.0.0.1 esp 84002 -m transport -ctx 1 1 "system_u:object_r:unlabeled_t:s3:c1.c5" -E 3des-cbc "06183223c23a21e8b36c566b" -A hmac-md5 "IPSETEST89ABCDEF"; - olly spdadd 10.0.0.2 10.0.0.1 any -ctx 1 1 "system_u:object_r:unlabeled_t:s3:c1.c5" -P out ipsec esp/transport//require; spdadd 10.0.0.1 10.0.0.2 any -ctx 1 1 "system_u:object_r:unlabeled_t:s3:c1.c5" -P in ipsec esp/transport//require; add 10.0.0.1 10.0.0.2 esp 84001 -m transport -ctx 1 1 "system_u:object_r:unlabeled_t:s3:c1.c5" -E 3des-cbc "06183223c23a21e8b36c566b" -A hmac-md5 "IPSETEST89ABCDEF"; add 10.0.0.2 10.0.0.1 esp 84002 -m transport -ctx 1 1 "system_u:object_r:unlabeled_t:s3:c1.c5" -E 3des-cbc "06183223c23a21e8b36c566b" -A hmac-md5 "IPSETEST89ABCDEF"; Any help would be greatly appreciated. -- paul moore linux security @ hp From drepper at redhat.com Thu Nov 16 20:21:57 2006 From: drepper at redhat.com (Ulrich Drepper) Date: Thu, 16 Nov 2006 12:21:57 -0800 Subject: [redhat-lspp] mqueue filesystem labeling In-Reply-To: <1163681772.7192.6.camel@localhost.localdomain> References: <455BFAC0.6070907@redhat.com> <1163681772.7192.6.camel@localhost.localdomain> Message-ID: <455CC865.2050904@redhat.com> Thiago Jung Bauermann wrote: > The problem I'm seeing happens even when using mq_open(3) to create a > new message queue, without mounting or explicitly using the mqueue > filesystem. That might very well be since mq_open implicitly works on the mqueue filesystem. I was talking about the mounted filesystem (if it is) and its use. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? From paul.moore at hp.com Thu Nov 16 20:40:01 2006 From: paul.moore at hp.com (Paul Moore) Date: Thu, 16 Nov 2006 15:40:01 -0500 Subject: [redhat-lspp] IPSec Configuration doc In-Reply-To: <455CC275.1060100@hp.com> References: <1163605143.17737.359.camel@faith.austin.ibm.com> <455CC275.1060100@hp.com> Message-ID: <455CCCA1.8090408@hp.com> Paul Moore wrote: > Joy Latten wrote: > >>Klaus requested some basic steps and info for >>configuring labeled ipsec. I started and came up with >>the following which can later be used to assist those >>new to labeled ipsec and wishing to understand and use it. >>This is by no means complete. I will fill in and improve >>in time. Let me know if anything is incorrect or can be improved. >> >>Currently, I am unable to successfully configure and run labeled >>ipsec in enforcing mode on lspp 55 kernel. I'm working on ironing out >>policy complaints so we can run in enforcing mode. Has anyone else >>tried this? > > > Thanks for sending this out. > > Based on your instructions I'm trying to setup a simple, manually keyed labeled > IPsec connection between two machines running the lspp.55 kernel; both are using > the MLS policy in permissive mode. Unfortunately, I can't seem to get it to > work; I assume I am doing something wrong but it is not obvious to me ... Well, nevermind that email ... I was sending traffic using the wrong context and since I was not using racoon it was dropped. -- paul moore linux security @ hp From mra at hp.com Thu Nov 16 21:09:45 2006 From: mra at hp.com (Matt Anderson) Date: Thu, 16 Nov 2006 16:09:45 -0500 Subject: [redhat-lspp] First login problem over ssh with polyinstantiated homedirs Message-ID: <455CD399.5030202@hp.com> Using the kickstart install to create users and setup /home to be a polyinstantiated directory we have been seeing a problem. when first attempting to login over ssh, after successfully authenticating, the connection is closed. When you try again the connection is allowed, but permission is denied on the user's home directory. Looking in the audit log and /var/log/secure reveal that pam_namespace is going though the process of creating the polyinstantiated directory and that process fails when it attempts to set the label and the DAC owner/group information. Adding an allow rule: allow sshd_t staff_home_t:dir { getattr setattr relabelto }; sshd can then set the label and DAC permissions for the home directory and both problems above go away. For staff_r at least, obviously the above rule needs to be extended for other types. -matt From mra at hp.com Thu Nov 16 21:21:24 2006 From: mra at hp.com (Matt Anderson) Date: Thu, 16 Nov 2006 16:21:24 -0500 Subject: [redhat-lspp] runcon in mls-enforcing Message-ID: <455CD654.7030609@hp.com> Is runcon intended to be used on an MLS system? Its bin_t and I don't see any policy for it included anywhere. Is this a targeted policy only program? -matt From latten at austin.ibm.com Thu Nov 16 20:59:31 2006 From: latten at austin.ibm.com (Joy Latten) Date: Thu, 16 Nov 2006 14:59:31 -0600 Subject: [redhat-lspp] IPSec Configuration doc In-Reply-To: <455CCCA1.8090408@hp.com> References: <1163605143.17737.359.camel@faith.austin.ibm.com> <455CC275.1060100@hp.com> <455CCCA1.8090408@hp.com> Message-ID: <1163710771.17737.379.camel@faith.austin.ibm.com> Is it working then? Joy On Thu, 2006-11-16 at 15:40 -0500, Paul Moore wrote: > Paul Moore wrote: > > Joy Latten wrote: > > > >>Klaus requested some basic steps and info for > >>configuring labeled ipsec. I started and came up with > >>the following which can later be used to assist those > >>new to labeled ipsec and wishing to understand and use it. > >>This is by no means complete. I will fill in and improve > >>in time. Let me know if anything is incorrect or can be improved. > >> > >>Currently, I am unable to successfully configure and run labeled > >>ipsec in enforcing mode on lspp 55 kernel. I'm working on ironing out > >>policy complaints so we can run in enforcing mode. Has anyone else > >>tried this? > > > > > > Thanks for sending this out. > > > > Based on your instructions I'm trying to setup a simple, manually keyed labeled > > IPsec connection between two machines running the lspp.55 kernel; both are using > > the MLS policy in permissive mode. Unfortunately, I can't seem to get it to > > work; I assume I am doing something wrong but it is not obvious to me ... > > Well, nevermind that email ... I was sending traffic using the wrong context and > since I was not using racoon it was dropped. > From paul.moore at hp.com Thu Nov 16 22:20:59 2006 From: paul.moore at hp.com (Paul Moore) Date: Thu, 16 Nov 2006 17:20:59 -0500 Subject: [redhat-lspp] IPSec Configuration doc In-Reply-To: <1163710771.17737.379.camel@faith.austin.ibm.com> References: <1163605143.17737.359.camel@faith.austin.ibm.com> <455CC275.1060100@hp.com> <455CCCA1.8090408@hp.com> <1163710771.17737.379.camel@faith.austin.ibm.com> Message-ID: <455CE44B.9030604@hp.com> Joy Latten wrote: > Is it working then? Yep, thanks. > On Thu, 2006-11-16 at 15:40 -0500, Paul Moore wrote: > >>Paul Moore wrote: >> >>>Joy Latten wrote: >>> >>> >>>>Klaus requested some basic steps and info for >>>>configuring labeled ipsec. I started and came up with >>>>the following which can later be used to assist those >>>>new to labeled ipsec and wishing to understand and use it. >>>>This is by no means complete. I will fill in and improve >>>>in time. Let me know if anything is incorrect or can be improved. >>>> >>>>Currently, I am unable to successfully configure and run labeled >>>>ipsec in enforcing mode on lspp 55 kernel. I'm working on ironing out >>>>policy complaints so we can run in enforcing mode. Has anyone else >>>>tried this? >>> >>> >>>Thanks for sending this out. >>> >>>Based on your instructions I'm trying to setup a simple, manually keyed labeled >>>IPsec connection between two machines running the lspp.55 kernel; both are using >>>the MLS policy in permissive mode. Unfortunately, I can't seem to get it to >>>work; I assume I am doing something wrong but it is not obvious to me ... >> >>Well, nevermind that email ... I was sending traffic using the wrong context and >>since I was not using racoon it was dropped. >> > > > -- > redhat-lspp mailing list > redhat-lspp at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-lspp -- paul moore linux security @ hp From vyekkirala at trustedcs.com Fri Nov 17 16:20:13 2006 From: vyekkirala at trustedcs.com (Venkat Yekkirala) Date: Fri, 17 Nov 2006 10:20:13 -0600 Subject: [redhat-lspp] LSPP Development Telecon 11/13/2006 Minutes In-Reply-To: <455C9CF2.80708@us.ibm.com> Message-ID: <000601c70a64$434bd8c0$cc0a010a@tcssec.com> > JL: ok, I'll do that. are there any of venkat's patches > in .55 kernel > EP: which patches ... > JL: venkat had set of 3 patches > EP: 55 has all three patches > GW: do we expect more patches from venkat > EP: I don't know of any. I am expecting the 3 config > change patches I am not aware of any outstanding patches. The 3 patches I last posted should warp-up labeled-ipsec work. Eric, can you please elaborate on the "3 config change patches" you were referring to in the above? From vyekkirala at trustedcs.com Fri Nov 17 16:21:03 2006 From: vyekkirala at trustedcs.com (Venkat Yekkirala) Date: Fri, 17 Nov 2006 10:21:03 -0600 Subject: [redhat-lspp] LSPP Development Telecon 11/13/2006 Minutes Message-ID: <000701c70a64$61af3c30$cc0a010a@tcssec.com> > -----Original Message----- > From: Venkat Yekkirala [mailto:vyekkirala at trustedcs.com]On Behalf Of > Venkat Yekkirala > Sent: Friday, November 17, 2006 10:20 AM > To: 'Loulwa Salem'; redhat-lspp at redhat.com; 'eparis at redhat.com' > Cc: Chad Hanson > Subject: RE: [redhat-lspp] LSPP Development Telecon 11/13/2006 Minutes > > > > JL: ok, I'll do that. are there any of venkat's patches > > in .55 kernel > > EP: which patches ... > > JL: venkat had set of 3 patches > > EP: 55 has all three patches > > GW: do we expect more patches from venkat > > EP: I don't know of any. I am expecting the 3 config > > change patches > > I am not aware of any outstanding patches. The 3 patches I last > posted should warp-up labeled-ipsec work. s/warp/wrap/ If the patches indeed warp-up, please let me know :) > > Eric, can you please elaborate on the "3 config change patches" > you were referring to in the above? > From eparis at redhat.com Fri Nov 17 16:32:10 2006 From: eparis at redhat.com (Eric Paris) Date: Fri, 17 Nov 2006 11:32:10 -0500 Subject: [redhat-lspp] LSPP Development Telecon 11/13/2006 Minutes In-Reply-To: <000601c70a64$434bd8c0$cc0a010a@tcssec.com> References: <000601c70a64$434bd8c0$cc0a010a@tcssec.com> Message-ID: <1163781130.22367.30.camel@localhost.localdomain> On Fri, 2006-11-17 at 10:20 -0600, Venkat Yekkirala wrote: > > JL: ok, I'll do that. are there any of venkat's patches > > in .55 kernel > > EP: which patches ... > > JL: venkat had set of 3 patches > > EP: 55 has all three patches > > GW: do we expect more patches from venkat > > EP: I don't know of any. I am expecting the 3 config > > change patches > > I am not aware of any outstanding patches. The 3 patches I last > posted should warp-up labeled-ipsec work. > > Eric, can you please elaborate on the "3 config change patches" > you were referring to in the above? I'm pretty sure I said "2 config change patches" and more correct would be "auditing config change patches" I think it was Joy who was working on the xfrm config change auditing (work in progress, see linux-audit) Paul should be working on making the NetLabel config change auditing not do anything if auditing is not enabled. I think he posted something, but I haven't looked at it closely. Only things I remember floating around which you may be interested/able to help on were the questions of denying unlabeled packets (I think you said this was easily done in policy) and the question of labels on connections back to localhost. I don't think I ever did hear a good solution to that one. I think you are all 'warped-up'. -Eric From paul.moore at hp.com Fri Nov 17 16:53:06 2006 From: paul.moore at hp.com (Paul Moore) Date: Fri, 17 Nov 2006 11:53:06 -0500 Subject: [redhat-lspp] LSPP Development Telecon 11/13/2006 Minutes In-Reply-To: <1163781130.22367.30.camel@localhost.localdomain> References: <000601c70a64$434bd8c0$cc0a010a@tcssec.com> <1163781130.22367.30.camel@localhost.localdomain> Message-ID: <455DE8F2.4090301@hp.com> Eric Paris wrote: > On Fri, 2006-11-17 at 10:20 -0600, Venkat Yekkirala wrote: > >>> JL: ok, I'll do that. are there any of venkat's patches >>>in .55 kernel >>> EP: which patches ... >>> JL: venkat had set of 3 patches >>> EP: 55 has all three patches >>> GW: do we expect more patches from venkat >>> EP: I don't know of any. I am expecting the 3 config >>>change patches >> >>I am not aware of any outstanding patches. The 3 patches I last >>posted should warp-up labeled-ipsec work. >> >>Eric, can you please elaborate on the "3 config change patches" >>you were referring to in the above? > > > I'm pretty sure I said "2 config change patches" and more correct would > be "auditing config change patches" > > I think it was Joy who was working on the xfrm config change auditing > (work in progress, see linux-audit) > > Paul should be working on making the NetLabel config change auditing not > do anything if auditing is not enabled. I think he posted something, > but I haven't looked at it closely. I have a small patch to take care of this which is part of a larger patchset going out today (would have gone out yesterday but DaveM rebased net-2.6.20 and then the kernel.org git servers decided to be a pain all of yesterday so I couldn't refresh). I have some other things going on this afternoon but I'll get the patches out before I leave tonight. -- paul moore linux security @ hp From dwalsh at redhat.com Fri Nov 17 18:45:59 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 17 Nov 2006 13:45:59 -0500 Subject: [redhat-lspp] runcon in mls-enforcing In-Reply-To: <455CD654.7030609@hp.com> References: <455CD654.7030609@hp.com> Message-ID: <455E0367.1080808@redhat.com> Matt Anderson wrote: > Is runcon intended to be used on an MLS system? Its bin_t and I don't > see any policy for it included anywhere. Is this a targeted policy only > program? > > -matt > > -- > redhat-lspp mailing list > redhat-lspp at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-lspp > It is really a test program. Does not work in enforcing mode on targeted either. You can use it to test out a policy via a shell setenforce 0 runcon -t httpd_t sh setenforce 1 From ltcgcw at us.ibm.com Fri Nov 17 22:42:32 2006 From: ltcgcw at us.ibm.com (George C. Wilson) Date: Fri, 17 Nov 2006 16:42:32 -0600 Subject: [redhat-lspp] [Reminder] Open LSPP Development Telecon Mon., Nov. 20 Message-ID: <20061117224232.GA26931@us.ibm.com> IBM hosts a telecon every Monday at 21:00 UTC 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 paul.moore at hp.com Fri Nov 17 23:01:11 2006 From: paul.moore at hp.com (Paul Moore) Date: Fri, 17 Nov 2006 18:01:11 -0500 Subject: [redhat-lspp] LSPP Development Telecon 11/13/2006 Minutes In-Reply-To: <455DE8F2.4090301@hp.com> References: <000601c70a64$434bd8c0$cc0a010a@tcssec.com> <1163781130.22367.30.camel@localhost.localdomain> <455DE8F2.4090301@hp.com> Message-ID: <455E3F37.4060300@hp.com> Paul Moore wrote: > Eric Paris wrote: > >>On Fri, 2006-11-17 at 10:20 -0600, Venkat Yekkirala wrote: >> >> >>>> JL: ok, I'll do that. are there any of venkat's patches >>>>in .55 kernel >>>> EP: which patches ... >>>> JL: venkat had set of 3 patches >>>> EP: 55 has all three patches >>>> GW: do we expect more patches from venkat >>>> EP: I don't know of any. I am expecting the 3 config >>>>change patches >>> >>>I am not aware of any outstanding patches. The 3 patches I last >>>posted should warp-up labeled-ipsec work. >>> >>>Eric, can you please elaborate on the "3 config change patches" >>>you were referring to in the above? >> >> >>I'm pretty sure I said "2 config change patches" and more correct would >>be "auditing config change patches" >> >>I think it was Joy who was working on the xfrm config change auditing >>(work in progress, see linux-audit) >> >>Paul should be working on making the NetLabel config change auditing not >>do anything if auditing is not enabled. I think he posted something, >>but I haven't looked at it closely. > > > I have a small patch to take care of this which is part of a larger patchset > going out today (would have gone out yesterday but DaveM rebased net-2.6.20 and > then the kernel.org git servers decided to be a pain all of yesterday so I > couldn't refresh). I have some other things going on this afternoon but I'll > get the patches out before I leave tonight. > For those of you playing along at home, I've submitted a patch and entered a bugzilla, number 216244. -- paul moore linux security @ hp From latten at austin.ibm.com Fri Nov 17 22:30:22 2006 From: latten at austin.ibm.com (Joy Latten) Date: Fri, 17 Nov 2006 16:30:22 -0600 Subject: [redhat-lspp] labeled ipsec policy Message-ID: <1163802623.17737.398.camel@faith.austin.ibm.com> The following policy enables labeled ipsec to run in enforcing mode. I configure labeled ipsec in sysadm_r role. Thus the rules I needed were specific to this role. This is just what I needed to get it to work and use labels, please feel free to modify this and make corrections. I was not sure if anyone had started this work. I am not sure where this should even reside in refpolicy modules. I apologize if this email gets long, but I wanted to make sure I tried to explain everything. Included are some interfaces, which I used in an xxxx.if file. Then, there are a bunch of rules which I used in a xxxx.te file These rules were just an example of what I needed to get ping, nc, and ssh to work with labeled ipsec. For my policy, I used the types unlabeled_t, passwd_t, and ipsec_spd_t. When using passwd_t, ipsec_spd_t or any other domain, please be mindful of mls constraints. I am still "playing" with labeled ipsec, so I don't think this policy is absolute and totally correct. :-) The interfaces: ipsec_set_label() -setkey needs to be able to add an ipsec policy containing a security context to the SPD. -racoon/setkey need to be able to add SAs containing security context to the SAD. -A sysadm would use this interface to enter the domain of the security context used in an ipsec policy entry. -A sysadm would also use this interface to enter the domain of the security context the SA will have. **NOTE: SAs pose a problem because there is the assumption you know the domain of the socket that will be created by an application. i.e, a ping proccess opens a socket with ping_t, thus SA's security context is also ping_t. sysadm would need to enter "ping_t" into this interface so the SA could be added to the SAD. ipsec_label_sa_pol() -Enter the domain of the SA and the domain of the ipsec policy. The SA will be considered "within the range" of the ipsec policy. i.e. the domain of your ipsec policy is ipsec_spd_t, you want ping_t SAs to be within range of ipsec_spd_t policy. racoon requires this in order to determine if a proposed SA "polmatches" to the SPD entry for the traffic stream. ipsec_labels_send_recv() -Allow a socket to send and receive with an IPSec SA. It is assumed that the type of the IPSec SA is the same as the domain of the socket which created and used it. ** NOTE: perhaps another interface is needed to allow a socket to use an SA of a different type than the socket. i.e. allow sshd_t sysadm_ssh_t:association recvfrom; ipsec_tools_utilites() -Enter the type of the process that can use setkey and racoon. -Actually, I kinda just grouped together all the rules that I needed to run racoon and setkey while in sysadm_r role. - I could not help but wonder if setkey and racoon should be run in sysadm_r role and transition into ipsec_t domain (see system/ipsec.te and system/ipsec.if) or left alone to run in sysadm domain. All the rules in this interface are when racoon and ipsec run in sysadm_t domain. NOTE: ideally it seems to me these rules should be in a *.te file. ----------------------------------------------------------------------------- xxxx.if ## Labeled IPSec ######################################## ## ## Allow setkey/racoon to add policy to the SPD or ## Security Associations to the SAD with the specified ## specified domain. ## ## ## ## Domain specified in security context of IPSec policy entry ## or IPSec SA. ## ## # interface(`ipsec_set_label',` gen_require(` type sysadm_t; ') allow sysadm_t $1:association setcontext; ') ######################################## ## ## Allow an IPSec SA to be within the range of an IPSec Policy. ## ## ## ## 1. The type of the IPSec SA ## 2. The type of the IPSec Policy ## ## # interface(`ipsec_label_sa_pol',` allow $1 $2:association polmatch; ') ######################################## ## ## Allow a socket to send and receive with an IPSec SA. ## Note: It is assumed that the type of the IPSec SA is same ## as the type of the socket that created it. ## ## ## ## 1. The type of the socket and the IPSec SA ## ## # interface(`ipsec_labels_send_recv',` allow $1 self:association { recvfrom sendto }; ') ######################################## ## ## Run ipsec utilities, setkey and racoon. ## ## ## ## The type of the proces performing this action. ## ## # interface(`ipsec_tools_utilities',` gen_require(` type isakmp_port_t; type inaddr_any_node_t; ') # allow setkey and racoon to create and use a key socket. allow $1 self:key_socket { create read write setopt }; # allow racoon to use ISAKMP port allow $1 isakmp_port_t:udp_socket name_bind; # allow racoon to use avc_has_perm in within_range() # to determine if proposed SA "polmatches" to policy allow $1 self:netlink_selinux_socket { bind create read }; # I think this is so racoon can listen on an admin port. allow $1 inaddr_any_node_t:tcp_socket node_bind; # to create, remove read lock in /var/racoon/ ipsec_manage_pid($1) # in grabmyaddrs() socket(PF_ROUTE...) allow $1 self:netlink_route_socket { create_netlink_socket_perms }; ') ------------------------------------------------------------------------- xxxx.te policy_module(ipsec_joy,1.0) gen_require(` type sysadm_t; type passwd_t; type ping_t; type unlabeled_t; type sysadm_ssh_t; type sshd_t; ') type ipsec_spd_t; ipsec_tools_utilities(sysadm_t) # use following domains in spd ipsec_set_label(unlabeled_t) ipsec_set_label(passwd_t) ipsec_set_label(ipsec_spd_t) # use following domains in SAs ipsec_set_label(ping_t) ipsec_set_label(sysadm_t) #for NC # allow specified SA to be considered within range of specified policy ipsec_label_sa_pol(ping_t, passwd_t) ipsec_label_sa_pol(sysadm_t, passwd_t) ipsec_label_sa_pol(ping_t, unlabeled_t) ipsec_label_sa_pol(sysadm_t, unlabeled_t) ipsec_label_sa_pol(ping_t, ipsec_spd_t) ipsec_label_sa_pol(sysadm_t, ipsec_spd_t) # allow SAs to be used for sending and receiving ipsec_labels_send_recv(ping_t) ipsec_labels_send_recv(sysadm_t) # for ssh ipsec_set_label(sysadm_ssh_t) ipsec_set_label(sshd_t) ipsec_label_sa_pol(sysadm_ssh_t, unlabeled_t) ipsec_label_sa_pol(sshd_t, unlabeled_t) ipsec_labels_send_recv(sshd_t) ipsec_labels_send_recv(sysadm_ssh_t) allow sysadm_ssh_t sshd_t:association recvfrom; allow sshd_t sysadm_ssh_t:association recvfrom; From latten at austin.ibm.com Mon Nov 20 15:09:42 2006 From: latten at austin.ibm.com (Joy Latten) Date: Mon, 20 Nov 2006 09:09:42 -0600 Subject: [redhat-lspp] labeled ipsec policy In-Reply-To: <200611201000.06118.pcmoore@engin.umich.edu> References: <1163802623.17737.398.camel@faith.austin.ibm.com> <200611201000.06118.pcmoore@engin.umich.edu> Message-ID: <1164035382.17737.408.camel@faith.austin.ibm.com> On Mon, 2006-11-20 at 10:00 -0500, Paul Moore wrote: > On Friday 17 November 2006 5:30 pm, Joy Latten wrote: > > The following policy enables labeled ipsec to run > > in enforcing mode. I configure labeled ipsec in sysadm_r role. > > Thus the rules I needed were specific to this role. > > I'll let the policy gurus comment on the rest of the policy, but I think that > we would want only the secadm_r role (in the MLS/LSPP policy) to be able to > configure labeled IPsec. Yes? > Actually, I wondered about this too. But when I took a look at the policy source, I noticed that in userdomain.te, sysadm_t was allowed to execute ipsec programs ipsec_exec_mgmt(sysadm_t), so I just assumed I should use sysadm_r role. Not sure if this was correct or not. Tried secadm_r role out of curiousity and got quite a lot of avc denied messages. So went with sysadm_r. :-) If secadm_r should be used, please let me know as I would need to get labeled ipsec working with policy in enforcing mode. Joy From paul.moore at hp.com Mon Nov 20 16:24:18 2006 From: paul.moore at hp.com (Paul Moore) Date: Mon, 20 Nov 2006 11:24:18 -0500 Subject: [redhat-lspp] labeled ipsec policy In-Reply-To: <1164035382.17737.408.camel@faith.austin.ibm.com> References: <1163802623.17737.398.camel@faith.austin.ibm.com> <200611201000.06118.pcmoore@engin.umich.edu> <1164035382.17737.408.camel@faith.austin.ibm.com> Message-ID: <200611201124.19292.paul.moore@hp.com> On Monday 20 November 2006 10:09 am, Joy Latten wrote: > On Mon, 2006-11-20 at 10:00 -0500, Paul Moore wrote: > > On Friday 17 November 2006 5:30 pm, Joy Latten wrote: > > > The following policy enables labeled ipsec to run > > > in enforcing mode. I configure labeled ipsec in sysadm_r role. > > > Thus the rules I needed were specific to this role. > > > > I'll let the policy gurus comment on the rest of the policy, but I think > > that we would want only the secadm_r role (in the MLS/LSPP policy) to be > > able to configure labeled IPsec. Yes? > > Actually, I wondered about this too. But when I took a look at the > policy source, I noticed that in userdomain.te, sysadm_t was allowed > to execute ipsec programs ipsec_exec_mgmt(sysadm_t), so I just assumed I > should use sysadm_r role. Not sure if this was correct or not. Tried > secadm_r role out of curiousity and got quite a lot of avc denied > messages. So went with sysadm_r. :-) Hmmm, I suspect this will probably be a problem as the IPsec management tools serve a dual purpose, they control the IPsec configuration (sysadm_r) as well as the policy relating to labeling SAs (secadm_r). I guess we'll just have to settle for sysadm_r and deal with the fact that sysadm_r is going to have some control over the system's security policy in this case. -- paul moore linux security @ hp From casey at schaufler-ca.com Mon Nov 20 16:34:09 2006 From: casey at schaufler-ca.com (Casey Schaufler) Date: Mon, 20 Nov 2006 08:34:09 -0800 (PST) Subject: [redhat-lspp] labeled ipsec policy In-Reply-To: <200611201124.19292.paul.moore@hp.com> Message-ID: <20061120163410.12804.qmail@web36611.mail.mud.yahoo.com> --- Paul Moore wrote: > Hmmm, I suspect this will probably be a problem as > the IPsec management tools > serve a dual purpose, they control the IPsec > configuration (sysadm_r) as well > as the policy relating to labeling SAs (secadm_r). > I guess we'll just have > to settle for sysadm_r and deal with the fact that > sysadm_r is going to have > some control over the system's security policy in > this case. Alternatively, you might consider a separate network security administrator role that is associated with those tools. It might be better than giving sysadm_r the additional responsibility. Casey Schaufler casey at schaufler-ca.com From sds at tycho.nsa.gov Mon Nov 20 17:53:09 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 20 Nov 2006 12:53:09 -0500 Subject: [redhat-lspp] mqueue filesystem labeling In-Reply-To: <1163557143.3930.2.camel@localhost.localdomain> References: <1163557143.3930.2.camel@localhost.localdomain> Message-ID: <1164045189.13758.17.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-11-15 at 00:19 -0200, Thiago Jung Bauermann wrote: > Hi folks, > > I am having some trouble with POSIX message queues in enforcing mode. I > hope someone can shed some light into this... > > The POSIX message queue implementation uses an internal virtual > filesystem called mqueue, so processes wanting to perform operations on > POSIX message queues must have access to that filesystem. > > The problem is that for some reason the mqueue filesystem is labeled at > SystemHigh, so only processes at that level are able to create message > queues. This kind of question belongs on selinux list (cc'd above), as it is not LSPP-specific. With regard to your question, I believe that this is a characteristic of fs_use_trans that has come up previously for other fs_use_trans filesystems - the root inode is deriving its label from the kernel's SID, and is thus inheriting SystemHigh as its level. For devpts, this was worked around via a restorecon /dev/pts in rc.sysinit, but the policy now supports range_transition statements on object classes, so it should be possible to define such a transition to label these pseudo filesystems with a correct level. > I don't think this is breaking any functionality, so... do we care? > > > > The only line I could find in the SELinux policy about this is: > > fs_use_trans mqueue gen_context(system_u:object_r:tmpfs_t,s0); > > The above says that the mqueue fs should be at SystemLow. > This is how the kernel initializes it: > > SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs > > Even if I explicitly set a SystemLow context for the filesystem when > mounting it, it is still mounted as SystemHigh: > > [root at alex mls]# mount -t mqueue mqueue /mnt > [root at alex mls]# ls -Zd /mnt > drwxrwxrwt root root system_u:object_r:tmpfs_t:SystemHigh /mnt > [root at alex mls]# umount /mnt > > [root at alex mls]# mount -o fscontext=system_u:object_r:tmpfs_t:s0 -t > mqueue mqueue /mnt > [root at alex mls]# ls -Zd /mnt > drwxrwxrwt root root system_u:object_r:tmpfs_t:SystemHigh /mnt > [root at alex mls]# umount /mnt > > [root at alex mls]# mount -o context=system_u:object_r:tmpfs_t:s0 -t mqueue > mqueue /mnt > [root at alex mls]# ls -Zd /mnt > drwxrwxrwt root root system_u:object_r:tmpfs_t:SystemHigh /mnt > > > > And here's the audit record generated when trying to create a message > queue in enforcing mode: > > ---- > type=PATH msg=audit(10/31/2006 17:00:00.603:752) : item=0 name=myqueue > obj=system_u:object_r:root_t:s0 > type=CWD msg=audit(10/31/2006 17:00:00.603:752) : cwd=/tmp/tests > > type=MQ_OPEN msg=audit(10/31/2006 17:00:00.603:752) : > oflag=0xc2 mode=777 mq_flags=0x6d8730 mq_maxmsg=16 mq_msgsize=1 > mq_curmsgs=0 > > type=SYSCALL msg=audit(10/31/2006 17:00:00.603:752) : arch=x86_64 > syscall=mq_open success=no exit=-13(Permission denied) a0=2aaaaab1f94d > a1=c2 a2=1ff a3=7fffac4d8550 items=1 ppid=2581 pid=2608 auid=ealuser > uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root > fsgid=root tty=pts0 comm=queuetest exe=/tmp/tests/queuetest > subj=staff_u:sysadm_r:sysadm_t:s0-s15:c0.c1023 key=(null) > ---- > > I got the above record by adding an audit rule for the mq_open() > syscall. I find it odd that it doesn't include an AVC message. I thought > every denial record had one... > > And here's an audit record obtained in permissive mode: > > ---- > type=PATH msg=audit(10/31/2006 17:01:12.307:764) : item=2 name=(null) > inode=418 dev=00:0d mode=dir,sticky,777 ouid=root ogid=root rdev=00:00 > obj=system_u:object_r:tmpfs_t:s15:c0.c1023 > > type=PATH msg=audit(10/31/2006 17:01:12.307:764) : item=1 name=(null) > inode=12076 dev=00:0d mode=file,755 ouid=root ogid=root rdev=00:00 > obj=staff_u:object_r:sysadm_tmpfs_t:s0 > > type=PATH msg=audit(10/31/2006 17:01:12.307:764) : item=0 name=myqueue > obj=system_u:object_r:root_t:s0 > > type=CWD msg=audit(10/31/2006 17:01:12.307:764) : > cwd=/tmp/tests > > type=MQ_OPEN msg=audit(10/31/2006 17:01:12.307:764) : oflag=0xc2 > mode=777 mq_flags=0x6d8730 mq_maxmsg=16 mq_msgsize=1 mq_curmsgs=0 > > type=SYSCALL msg=audit(10/31/2006 17:01:12.307:764) : arch=x86_64 > syscall=mq_open success=yes exit=4 a0=2aaaaab1f94d a1=c2 a2=1 > ff a3=7fffac4d8550 items=3 ppid=2581 pid=2608 auid=ealuser uid=root > gid=root euid=root suid=root fsuid=root egid=root sgid=root > fsgid=root tty=pts0 comm=queuetest exe=/tmp/tests/queuetest > subj=staff_u:sysadm_r:sysadm_t:s0-s15:c0.c1023 key=(null) > > type=AVC msg=audit(10/31/2006 17:01:12.307:764) : avc: denied > { add_name } for pid=2608 comm=queuetest name=myqueue scontext= > staff_u:sysadm_r:sysadm_t:s0-s15:c0.c1023 > tcontext=system_u:object_r:tmpfs_t:s15:c0.c1023 tclass=dir > > type=AVC msg=audit(10/31/2006 17:01:12.307:764) : avc: denied > { write } for pid=2608 comm=queuetest name=/ dev=mqueue ino=418 s > context=staff_u:sysadm_r:sysadm_t:s0-s15:c0.c1023 > tcontext=system_u:object_r:tmpfs_t:s15:c0.c1023 tclass=dir > ---- > > > -- > []'s > Thiago Jung Bauermann > Software Engineer > IBM Linux Technology Center > > -- > redhat-lspp mailing list > redhat-lspp at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-lspp -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Mon Nov 20 18:59:09 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 20 Nov 2006 13:59:09 -0500 Subject: [redhat-lspp] Re: anyway to reverse a dontaudit rule? In-Reply-To: <455B8F79.4020504@mentalrootkit.com> References: <1163616448.17737.368.camel@faith.austin.ibm.com> <455B8F79.4020504@mentalrootkit.com> Message-ID: <1164049149.13758.41.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-11-15 at 17:06 -0500, Karl MacMillan wrote: > Joy Latten wrote: > > Is there a way to reverse a dontaudit rule without having to > > modify and recompile base policy? > > I need to see the audit message to help determine what permissions > > are being denied for a particular application. > > > > No - that is why the enableaudit.pp base policy is provided in > /usr/share/selinux/[policyname]/enableaudit.pp. Install that with: > > semodule -b path_to_enableaudit > > and you should see all denials. ...that would have been suppressed by dontaudit rules in the base module. But not dontaudit rules in non-base modules. -- Stephen Smalley National Security Agency From thompsmc at us.ibm.com Mon Nov 20 22:01:15 2006 From: thompsmc at us.ibm.com (Michael C Thompson) Date: Mon, 20 Nov 2006 16:01:15 -0600 Subject: [redhat-lspp] LSPP Development Telecon 11/20/2006 Minutes Message-ID: <456225AB.906@us.ibm.com> 11/20/2006 lspp Meeting Minutes: =============================== Attendees George Wilson (IBM) - GW Linda Knippers (HP) - LK James Antill (RH) - JA Paul Moore (HP) - PM Bill O'Donnel (SGI) Chad Hansen (TCS) Mike Thompson (IBM) - MT Scott Lawler (Lightspeed) Kylene Hall (IBM) Steve Grubb (RH) - SG Dan Walsh (RH) - DW Joy Latten (IBM) - JL Please forgive if anything was omiited or anyone's name was not captured. Kernel / Beta / rawhide update ------------------------------ GW: Beta2 issues can not be discussed, since it is not an open beta GW: There is an selinux translation issue filed, and there have been testing w/ 55 kernel, no issues found LK: What are the differences between lspp.55 and beta2 SG: Eric's and Paul's patches added GW: Should we continue to use the lspp.55 kernel until we hear otherwise? SG: Yes, its pretty recent and Joy is almost done with her ipsec patch and paul has new patches, thus the need for an lspp kernel LK: What policy should we be running? DW: Run the rawhide policy, they are planning to be 1-1. RHEL5 policy will be taken from rawhide policy SG: If you see something that looks wrong, file a bug. If its not a bug, we'll close it as such, otherwise, we'll fix it. SELinux base and MLS policy update --------------------------------------------- GW: There is a translation bug LK: Matt said that its fixed in rawhide policy DW: Yeah, this is fixed in rawhide GW: Yes, we've seen it on one of the installs DW: I'll look into it and verify that c1023 is used, not c255. Please send me any policy bugs or questions in email GW: Any other policy issues? PAM & VFS polyinstantiation --------------------------- GW: Been playing with James' level selection, but can't get it to work in enforcing, or non-enforcing mode DW: its failing to do the mkdir? GW: no, getting a pam conversation error DW: any avc messages? GW: in enforcing mode, root ssh can't login, but session gets opened, although conversation failed. On the console, root seems to work, I get session opened, and I get to the selection prompt, but I get invalid security context or if no, an authentication error (in enforcing). It works in permissive for root at console, and nothing works for normal users. JA: It could be policy GW: Not getting avc, am doing on ppc64, are you on i386? JA: Yeah, been testing on i386 GW: I'll try and get you more useful data, it will probably boil down to policy. Will try to get Klaus to get a look at it once he is back from vacation. GW: Got aid policy built newrole ------- GW: Mike's newrole patches went up stream, Mike, anything to saw on that? MT: yay, that's about it :) CIPSO / IPsec ------------- GW: ok, any news on cipso? PM: no real news JL: Labeled ipsec awaiting on Klaus to get back so we can get a read on LSPP's requirements for IPsec toggles. Sent out the policy to get ipsec working in enforcing mode Audit ----- GW: News on audit? SG: Nope Self tests / aide ----------------- GW: Still hacking on self test, added some BLP checks, not sure how to other more DW: Can do testing through run_init GW: Testing will start at SystemHigh, but we would like to change level DW: Well, you could write scripts at different levels and use run_init to execute them to test GW: Still figuring python syntax, can create object to pass into audit_get_reply SG: Dan said he was going to work on the python bindings GW: Not clear that it has bugs, i created a new object and it does like that, but not sure on how to make use of that reply object DW: That object is supposed to go to the next func, but that next func is broken. GW: Took aid policy module and got it built and inserted, compile without any problems Cron, tmpwatch, mail, etc. -------------------------- GW: Has anyone had time to test cron and mail? JA: The policy level selection code relies on policy like cron, so there if level selection has problems, cron might have problems GW: OK, we might want to run some cron jobs Final cutoff dates ------------------ GW: The final cutoff dates are coming up soon Final thoughts -------------- GW: Please, write bugs for everything and open them up if you are willing to do that Happy Thanksgiving! From cpebenito at tresys.com Tue Nov 21 14:10:02 2006 From: cpebenito at tresys.com (Christopher J. PeBenito) Date: Tue, 21 Nov 2006 09:10:02 -0500 Subject: [redhat-lspp] Re: labeled ipsec policy In-Reply-To: <1163802623.17737.398.camel@faith.austin.ibm.com> References: <1163802623.17737.398.camel@faith.austin.ibm.com> Message-ID: <1164118202.12234.24.camel@sgc> On Fri, 2006-11-17 at 16:30 -0600, Joy Latten wrote: > The following policy enables labeled ipsec to run > in enforcing mode. I configure labeled ipsec in sysadm_r role. > Thus the rules I needed were specific to this role. [cut] > Included are some interfaces, which I used in an xxxx.if > file. Then, there are a bunch of rules which I used in a xxxx.te file > These rules were just an example of what I needed > to get ping, nc, and ssh to work with labeled ipsec. For my > policy, I used the types unlabeled_t, passwd_t, and ipsec_spd_t. > When using passwd_t, ipsec_spd_t or any other domain, please be > mindful of mls constraints. [cut] > interface(`ipsec_set_label',` > gen_require(` > type sysadm_t; > ') > > allow sysadm_t $1:association setcontext; > ') Interfaces are written from the perspective of the subject (except for a few very specific cases), so the parameter should be the subject, not the object. Neglecting that, is this for sysadm_t instead of ipsec_mgmt_t? I suspect that we want to add an interface to the domain module that allows setcontext on the domain attribute. > interface(`ipsec_label_sa_pol',` > allow $1 $2:association polmatch; > ') Generally refpolicy would leave this as a raw rule these types are in separate modules, in which case the interface would be in $2's module and have a specific type instead of $2. > interface(`ipsec_labels_send_recv',` > allow $1 self:association { recvfrom sendto }; > ') This would be raw rule in refpolicy instead of an interface. > interface(`ipsec_tools_utilities',` > gen_require(` > type isakmp_port_t; > type inaddr_any_node_t; > ') > > # allow setkey and racoon to create and use a key socket. > allow $1 self:key_socket { create read write setopt }; > > # allow racoon to use ISAKMP port > allow $1 isakmp_port_t:udp_socket name_bind; > > # allow racoon to use avc_has_perm in within_range() > # to determine if proposed SA "polmatches" to policy > allow $1 self:netlink_selinux_socket { bind create read }; > > # I think this is so racoon can listen on an admin port. > allow $1 inaddr_any_node_t:tcp_socket node_bind; > > # to create, remove read lock in /var/racoon/ > ipsec_manage_pid($1) > > # in grabmyaddrs() socket(PF_ROUTE...) > allow $1 self:netlink_route_socket { create_netlink_socket_perms }; > ') Again, why is this needed, instead of ipsec_mgmt_t? I suspect that the ipsec policy needs to be overhauled because I believe it was oriented towards the KAME ipsec implementation (pluto, et al) and was augmented to work with racoon afterwards. -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 From dwalsh at redhat.com Wed Nov 22 18:16:31 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 22 Nov 2006 13:16:31 -0500 Subject: [redhat-lspp] I think the best option for now is Message-ID: <456493FF.9070507@redhat.com> import audit fd=audit.audit_open() print audit.audit_is_enabled(fd) Getting the current get_reply bindings to work is going to be very difficult. Dan From ltcgcw at us.ibm.com Mon Nov 27 19:45:36 2006 From: ltcgcw at us.ibm.com (George C. Wilson) Date: Mon, 27 Nov 2006 13:45:36 -0600 Subject: [redhat-lspp] I think the best option for now is In-Reply-To: <456493FF.9070507@redhat.com> References: <456493FF.9070507@redhat.com> Message-ID: <20061127194536.GA30881@us.ibm.com> On Wed, Nov 22, 2006 at 01:16:31PM -0500, Daniel J Walsh wrote: > > import audit > fd=audit.audit_open() > print audit.audit_is_enabled(fd) > > Getting the current get_reply bindings to work is going to be very > difficult. > Yeah, it don't think it will be straightforward. I got this hokey code to satisty the method call: inreply = audit.audit_reply() rc = audit.audit_get_reply(fd, inreply, audit.GET_REPLY_BLOCKING, 0) Which obviously can't work without some notion of call by reference. From looking at the SWIG documentation, a C struct passed by pointer and modified would be passed out of the python method as an additional return value. So, something like rc, reply = audit.audit_get_reply(fd, audit.GET_REPLY_BLOCKING, 0) is more what I'd expect the method invocation to look like. Is audit.audit_is_enabled() sufficient? It only returns whether audit is enabled, not necessarily alive, right? -- George Wilson IBM Linux Technology Center From ltcgcw at us.ibm.com Mon Nov 27 19:47:26 2006 From: ltcgcw at us.ibm.com (George C. Wilson) Date: Mon, 27 Nov 2006 13:47:26 -0600 Subject: [redhat-lspp] [Reminder] Open LSPP Development Telecon Mon., Nov. 27 Message-ID: <20061127194725.GA32479@us.ibm.com> IBM hosts a telecon every Monday at 21:00 UTC 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 latten at austin.ibm.com Mon Nov 27 20:51:20 2006 From: latten at austin.ibm.com (Joy Latten) Date: Mon, 27 Nov 2006 14:51:20 -0600 Subject: [redhat-lspp] Re: labeled ipsec policy In-Reply-To: <1164118202.12234.24.camel@sgc> References: <1163802623.17737.398.camel@faith.austin.ibm.com> <1164118202.12234.24.camel@sgc> Message-ID: <1164660680.17737.459.camel@faith.austin.ibm.com> On Tue, 2006-11-21 at 09:10 -0500, Christopher J. PeBenito wrote: > On Fri, 2006-11-17 at 16:30 -0600, Joy Latten wrote: > > The following policy enables labeled ipsec to run > > in enforcing mode. I configure labeled ipsec in sysadm_r role. > > Thus the rules I needed were specific to this role. > [cut] > > Included are some interfaces, which I used in an xxxx.if > > file. Then, there are a bunch of rules which I used in a xxxx.te file > > These rules were just an example of what I needed > > to get ping, nc, and ssh to work with labeled ipsec. For my > > policy, I used the types unlabeled_t, passwd_t, and ipsec_spd_t. > > When using passwd_t, ipsec_spd_t or any other domain, please be > > mindful of mls constraints. > [cut] > > > interface(`ipsec_set_label',` > > gen_require(` > > type sysadm_t; > > ') > > > > allow sysadm_t $1:association setcontext; > > ') > > Interfaces are written from the perspective of the subject (except for a > few very specific cases), so the parameter should be the subject, not > the object. Neglecting that, is this for sysadm_t instead of > ipsec_mgmt_t? I suspect that we want to add an interface to the domain > module that allows setcontext on the domain attribute. Yes, this was for sysadm_t. I had taken a look at the current ipsec.if, ipsec.te, ipsec.fc and userdomain.te files as well and had wondered why we were not executing ipsec in the ipsec domain. It seem that the policy in those files was more for pluto and its utilities than ipsec-tools' utilities. So should racoon and setkey, the ipsec-tools' utiltites, be run in the ipsec domain? Should the sysadm_r role only be allowed to configure ipsec? > > interface(`ipsec_label_sa_pol',` > > allow $1 $2:association polmatch; > > ') > > Generally refpolicy would leave this as a raw rule these types are in > separate modules, in which case the interface would be in $2's module > and have a specific type instead of $2. Ok, I think I understand what you mean. From what I can tell of the code for the "polmatch" permission, $2 will most likely always be the type of the security context in the ipsec policy. However, this could be set to anything by the sysadm. Should I setup a default? For example, assume labeled ipsec policy to have a type of ipsec_spd_t? Thus a sysadm who decides to use labels in his ipsec policy, by default could use ipsec_spd_t for the type and specify whatever he/she wants for the mls level. Then he/she would use the interface to say which domains he wants to allow to "polmatch" to this. Does this sound reasonable? If so, I'll make the change and also make sure this is documented. > > interface(`ipsec_labels_send_recv',` > > allow $1 self:association { recvfrom sendto }; > > ') > > This would be raw rule in refpolicy instead of an interface. I am not too sure I understand. We need a rule allowing flow->sid to use SA's sid to send. SA's type as well as flow's type will be that of the socket. Thus it could be any application or daemon. Do I need to add this rule to every daemon/application as a raw rule? For example, in netutils.te, add this for ping? > > interface(`ipsec_tools_utilities',` > > gen_require(` > > type isakmp_port_t; > > type inaddr_any_node_t; > > ') > > > > # allow setkey and racoon to create and use a key socket. > > allow $1 self:key_socket { create read write setopt }; > > > > # allow racoon to use ISAKMP port > > allow $1 isakmp_port_t:udp_socket name_bind; > > > > # allow racoon to use avc_has_perm in within_range() > > # to determine if proposed SA "polmatches" to policy > > allow $1 self:netlink_selinux_socket { bind create read }; > > > > # I think this is so racoon can listen on an admin port. > > allow $1 inaddr_any_node_t:tcp_socket node_bind; > > > > # to create, remove read lock in /var/racoon/ > > ipsec_manage_pid($1) > > > > # in grabmyaddrs() socket(PF_ROUTE...) > > allow $1 self:netlink_route_socket { create_netlink_socket_perms }; > > ') > > Again, why is this needed, instead of ipsec_mgmt_t? > > I suspect that the ipsec policy needs to be overhauled because I believe > it was oriented towards the KAME ipsec implementation (pluto, et al) and > was augmented to work with racoon afterwards. I think you are correct. Right now racoon and setkey use ipsec_exec_t domain. Is this ok or should it be ipsec_mgmt_t? Also, should I go ahead and make the modifications for racoon and setkey to run in the ipsec domain (either ipsec_exec_t or ipsec_mgmt_t) instead of sysadm_t domain ? I wouldn't mind making an attempt at it with your help and as long as I knew you would review it for me. Regards, Joy From dwalsh at redhat.com Mon Nov 27 21:32:39 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 27 Nov 2006 16:32:39 -0500 Subject: [redhat-lspp] I think the best option for now is In-Reply-To: <20061127194536.GA30881@us.ibm.com> References: <456493FF.9070507@redhat.com> <20061127194536.GA30881@us.ibm.com> Message-ID: <456B5977.6090906@redhat.com> George C. Wilson wrote: > On Wed, Nov 22, 2006 at 01:16:31PM -0500, Daniel J Walsh wrote: > >> import audit >> fd=audit.audit_open() >> print audit.audit_is_enabled(fd) >> >> Getting the current get_reply bindings to work is going to be very >> difficult. >> >> > > Yeah, it don't think it will be straightforward. I got this hokey code > to satisty the method call: > > inreply = audit.audit_reply() > rc = audit.audit_get_reply(fd, inreply, audit.GET_REPLY_BLOCKING, 0) > > Which obviously can't work without some notion of call by reference. From > looking at the SWIG documentation, a C struct passed by pointer and modified > would be passed out of the python method as an additional return value. So, > something like > > rc, reply = audit.audit_get_reply(fd, audit.GET_REPLY_BLOCKING, 0) > > is more what I'd expect the method invocation to look like. > > Is audit.audit_is_enabled() sufficient? It only returns whether audit is > enabled, not necessarily alive, right? > > audit_reply is checking that the status is running. It is doing the equivalent of what you were trying to do. Steve Grubb wants to discourage this use of this function, so that people do not do if (audit_reply()) { audit_send() } But would rather just audit_send() From linda.knippers at hp.com Mon Nov 27 23:46:34 2006 From: linda.knippers at hp.com (Linda Knippers) Date: Mon, 27 Nov 2006 18:46:34 -0500 Subject: [redhat-lspp] /tmp polyinstantiation and the man command Message-ID: <456B78DA.4010909@hp.com> During today's conference call I mentioned a problem I'm seeing where the man command doesn't work for certain users in certain roles. I also mentioned separately that I have a problem accessing /tmp at times. Turns out these problems are related. Whenever I can't access /tmp the man command will fail. I hadn't noticed an AVC deny before but there's one from the mktemp command: type=AVC msg=audit(1164668073.122:853): avc: denied { write } for pid=5160 comm="mktemp" name="system_u:object_r:staff_tmp_t:SystemLow_ljk" dev=dm-0 ino=1015810 scontext=staff_u:secadm_r:secadm_t:s0-s15:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=dir type=SYSCALL msg=audit(1164668073.122:853): arch=40000003 syscall=5 success=no exit=-13 a0=9a80008 a1=c2 a2=180 a3=9a80008 items=0 ppid=5156 pid=5160 auid=501 uid=501 gid=501 euid=501 suid=501 fsuid=501 egid=501 sgid=501 fsgid=501 tty=pts1 comm="mktemp" exe="/bin/mktemp" subj=staff_u:secadm_r:secadm_t:s0-s15:c0.c1023 key=(null) I get similar messages if I try: -bash-3.1$ touch /tmp/foo touch: cannot touch `/tmp/foo': Permission denied With my current example, the only way my non-root administrative user can access /tmp is in the sysadm_r role. In the staff_r or secadm_r roles, the user can't access /tmp. I looked in /var/log/secure for messages and I see the /tmp directory being set up when the user logs. I get messages like: Nov 27 18:15:57 kipper sshd[5661]: pam_namespace(sshd:session): poly_name system_u:object_r:staff_tmp_t:SystemLow_ljk Nov 27 18:15:57 kipper sshd[5661]: pam_namespace(sshd:session): Inst ctxt system_u:object_r:staff_tmp_t:SystemLow Orig ctxt system_u:object_r:tmp_t:SystemLow-s15:c0.c1023 but I don't see any messages for any of the newroles. Now this is starting to ring a bell. Didn't someone mention something recently about configuring pam for newrole? My system is installed using the latest kitstart script but maybe there's a problem with the setup? I also can't get to the home directory for any user so I've got problems there too. Klaus, are you seeing the same behavior? Does anyone have a configuration with polyinstantiation working? If so, any advice? --ljk From latten at austin.ibm.com Mon Nov 27 23:47:38 2006 From: latten at austin.ibm.com (Joy Latten) Date: Mon, 27 Nov 2006 17:47:38 -0600 Subject: [redhat-lspp] labeled ipsec over loopback Message-ID: <1164671259.17737.466.camel@faith.austin.ibm.com> As per today's LSPP call, regular ipsec works ok over loopback. However, I could not get labeled ipsec to work over loopback. I will investigate to see why. Also, you must set to false /proc/sys/net/ipv4/conf/lo/disable_xfrm and /proc/sys/net/ipv4/conf/lo/disable_policy. By default they are set to true. Regards, Joy From sds at tycho.nsa.gov Tue Nov 28 13:09:25 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 28 Nov 2006 08:09:25 -0500 Subject: [redhat-lspp] /tmp polyinstantiation and the man command In-Reply-To: <456B78DA.4010909@hp.com> References: <456B78DA.4010909@hp.com> Message-ID: <1164719365.13758.250.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2006-11-27 at 18:46 -0500, Linda Knippers wrote: > During today's conference call I mentioned a problem I'm seeing > where the man command doesn't work for certain users in certain > roles. I also mentioned separately that I have a problem accessing > /tmp at times. Turns out these problems are related. Whenever I > can't access /tmp the man command will fail. I hadn't noticed an > AVC deny before but there's one from the mktemp command: > > type=AVC msg=audit(1164668073.122:853): avc: denied { write } for pid=5160 > comm="mktemp" name="system_u:object_r:staff_tmp_t:SystemLow_ljk" dev=dm-0 > ino=1015810 scontext=staff_u:secadm_r:secadm_t:s0-s15:c0.c1023 > tcontext=system_u:object_r:default_t:s0 tclass=dir > type=SYSCALL msg=audit(1164668073.122:853): arch=40000003 syscall=5 success=no > exit=-13 a0=9a80008 a1=c2 a2=180 a3=9a80008 items=0 ppid=5156 pid=5160 auid=501 > uid=501 gid=501 euid=501 suid=501 fsuid=501 egid=501 sgid=501 fsgid=501 tty=pts1 > comm="mktemp" exe="/bin/mktemp" subj=staff_u:secadm_r:secadm_t:s0-s15:c0.c1023 > key=(null) > > I get similar messages if I try: > -bash-3.1$ touch /tmp/foo > touch: cannot touch `/tmp/foo': Permission denied > > With my current example, the only way my non-root administrative user > can access /tmp is in the sysadm_r role. In the staff_r or secadm_r > roles, the user can't access /tmp. > > I looked in /var/log/secure for messages and I see the /tmp directory > being set up when the user logs. I get messages like: > > Nov 27 18:15:57 kipper sshd[5661]: pam_namespace(sshd:session): poly_name > system_u:object_r:staff_tmp_t:SystemLow_ljk > Nov 27 18:15:57 kipper sshd[5661]: pam_namespace(sshd:session): Inst ctxt > system_u:object_r:staff_tmp_t:SystemLow Orig ctxt > system_u:object_r:tmp_t:SystemLow-s15:c0.c1023 > > but I don't see any messages for any of the newroles. Now > this is starting to ring a bell. Didn't someone mention something recently > about configuring pam for newrole? My system is installed using the latest > kitstart script but maybe there's a problem with the setup? > > I also can't get to the home directory for any user so I've got > problems there too. > > Klaus, are you seeing the same behavior? > > Does anyone have a configuration with polyinstantiation working? If so, > any advice? Version of policycoreutils-newrole and selinux-policy-mls? Contents of /etc/pam.d/newrole? -- Stephen Smalley National Security Agency From linda.knippers at hp.com Tue Nov 28 15:41:11 2006 From: linda.knippers at hp.com (Linda Knippers) Date: Tue, 28 Nov 2006 10:41:11 -0500 Subject: [redhat-lspp] /tmp polyinstantiation and the man command In-Reply-To: <1164719365.13758.250.camel@moss-spartans.epoch.ncsc.mil> References: <456B78DA.4010909@hp.com> <1164719365.13758.250.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <456C5897.4050708@hp.com> Stephen Smalley wrote: > Version of policycoreutils-newrole and selinux-policy-mls? > Contents of /etc/pam.d/newrole? Sorry, I'd mentioned in the call that I was running the latest from Dan's people page but omitted it from the mail. I have these rpms. policycoreutils-1.33.2-2.el5 policycoreutils-newrole-1.33.2-2.el5 selinux-policy-mls-2.4.5-3.el5 selinux-policy-2.4.5-3.el5 /etc/pam.d/newrole has this: #%PAM-1.0 auth include system-auth account include system-auth password include system-auth session include system-auth session optional pam_xauth.so -- ljk From sds at tycho.nsa.gov Tue Nov 28 15:43:22 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 28 Nov 2006 10:43:22 -0500 Subject: [redhat-lspp] /tmp polyinstantiation and the man command In-Reply-To: <456C5897.4050708@hp.com> References: <456B78DA.4010909@hp.com> <1164719365.13758.250.camel@moss-spartans.epoch.ncsc.mil> <456C5897.4050708@hp.com> Message-ID: <1164728602.23019.1.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2006-11-28 at 10:41 -0500, Linda Knippers wrote: > Stephen Smalley wrote: > > > Version of policycoreutils-newrole and selinux-policy-mls? > > Contents of /etc/pam.d/newrole? > > Sorry, I'd mentioned in the call that I was running the latest from > Dan's people page but omitted it from the mail. I have these > rpms. > > policycoreutils-1.33.2-2.el5 > policycoreutils-newrole-1.33.2-2.el5 > selinux-policy-mls-2.4.5-3.el5 > selinux-policy-2.4.5-3.el5 > > /etc/pam.d/newrole has this: > #%PAM-1.0 > auth include system-auth > account include system-auth > password include system-auth > session include system-auth > session optional pam_xauth.so I would have expected the latter to include: session required pam_namespace.so unmnt_remnt no_unmount_on_close -- Stephen Smalley National Security Agency From linda.knippers at hp.com Tue Nov 28 16:01:45 2006 From: linda.knippers at hp.com (Linda Knippers) Date: Tue, 28 Nov 2006 11:01:45 -0500 Subject: [redhat-lspp] /tmp polyinstantiation and the man command In-Reply-To: <1164728602.23019.1.camel@moss-spartans.epoch.ncsc.mil> References: <456B78DA.4010909@hp.com> <1164719365.13758.250.camel@moss-spartans.epoch.ncsc.mil> <456C5897.4050708@hp.com> <1164728602.23019.1.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <456C5D69.5040201@hp.com> Stephen Smalley wrote: > On Tue, 2006-11-28 at 10:41 -0500, Linda Knippers wrote: > >>Stephen Smalley wrote: >> >> >>>Version of policycoreutils-newrole and selinux-policy-mls? >>>Contents of /etc/pam.d/newrole? >> >>Sorry, I'd mentioned in the call that I was running the latest from >>Dan's people page but omitted it from the mail. I have these >>rpms. >> >>policycoreutils-1.33.2-2.el5 >>policycoreutils-newrole-1.33.2-2.el5 >>selinux-policy-mls-2.4.5-3.el5 >>selinux-policy-2.4.5-3.el5 >> >>/etc/pam.d/newrole has this: >>#%PAM-1.0 >>auth include system-auth >>account include system-auth >>password include system-auth >>session include system-auth >>session optional pam_xauth.so > > > I would have expected the latter to include: > session required pam_namespace.so unmnt_remnt no_unmount_on_close I added that line but I don't see any difference in behavior. I added it at the end. Does the location matter? (Sorry for the dumb pam question). -- ljk From sds at tycho.nsa.gov Tue Nov 28 17:54:35 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 28 Nov 2006 12:54:35 -0500 Subject: [redhat-lspp] /tmp polyinstantiation and the man command In-Reply-To: <456C5D69.5040201@hp.com> References: <456B78DA.4010909@hp.com> <1164719365.13758.250.camel@moss-spartans.epoch.ncsc.mil> <456C5897.4050708@hp.com> <1164728602.23019.1.camel@moss-spartans.epoch.ncsc.mil> <456C5D69.5040201@hp.com> Message-ID: <1164736475.23019.12.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2006-11-28 at 11:01 -0500, Linda Knippers wrote: > Stephen Smalley wrote: > > On Tue, 2006-11-28 at 10:41 -0500, Linda Knippers wrote: > > > >>Stephen Smalley wrote: > >> > >> > >>>Version of policycoreutils-newrole and selinux-policy-mls? > >>>Contents of /etc/pam.d/newrole? > >> > >>Sorry, I'd mentioned in the call that I was running the latest from > >>Dan's people page but omitted it from the mail. I have these > >>rpms. > >> > >>policycoreutils-1.33.2-2.el5 > >>policycoreutils-newrole-1.33.2-2.el5 > >>selinux-policy-mls-2.4.5-3.el5 > >>selinux-policy-2.4.5-3.el5 > >> > >>/etc/pam.d/newrole has this: > >>#%PAM-1.0 > >>auth include system-auth > >>account include system-auth > >>password include system-auth > >>session include system-auth > >>session optional pam_xauth.so > > > > > > I would have expected the latter to include: > > session required pam_namespace.so unmnt_remnt no_unmount_on_close > > I added that line but I don't see any difference in behavior. I added > it at the end. Does the location matter? (Sorry for the dumb pam question). Possibly, e.g. if there is a sufficient or requisite module in the system-auth stack. Easiest thing to do is to move it up to the first one and try again. But now I am wondering whether that policycoreutils was built with LSPP_PRIV=y, which is required to enable the audit and namespace functionality. The fedora devel .spec file still has LOG_AUDIT_PRIV=y, which was the old flag for building with audit support and no longer is used. ls -l /usr/bin/newrole -- Stephen Smalley National Security Agency From sgrubb at redhat.com Tue Nov 28 18:33:51 2006 From: sgrubb at redhat.com (Steve Grubb) Date: Tue, 28 Nov 2006 13:33:51 -0500 Subject: [redhat-lspp] lspp 56 kernel released Message-ID: <200611281333.51689.sgrubb@redhat.com> Hi, The lspp.56 kernel has been published to the lspp yum repo at: http://people.redhat.com/sgrubb/files/lspp These will likely make RHEL5 GA: - Fix cipso oops issues (Paul Moore) - Disallow direct editing of ip option on cipso labeled packets (Paul Moore) - Complete fix for correct getpeercon() results (Venkat Yekkirala) - Audit xfrm configuration changes (Joy Latten) - Do not audit netlabel config changes if audit is off (Paul Moore) - Fix bugs in netlabel code, patches 6,8,12 of the 13 send on 11/17 (Paul Moore) This will hopefully make RHEL5 GA (but no guarantee): - Improve performance in netlabel code, patches 2,3,4,5,10 of 13 (Paul Moore) This might now make RHEL5 GA: - General clean up and preparation for future work in netlabel, patches 1,7,9,11 (Paul Moore) Please let me know if there any problems with this kernel. -Steve From thompsmc at us.ibm.com Tue Nov 28 21:25:17 2006 From: thompsmc at us.ibm.com (Michael C Thompson) Date: Tue, 28 Nov 2006 15:25:17 -0600 Subject: [redhat-lspp] LSPP Development Telecon 11/27/2006 Minutes Message-ID: <456CA93D.6080703@us.ibm.com> 11/27/2006 LSPP Meeting Minutes: =============================== Attendees George Wilson (IBM) - GW Mike Thompson (IBM) - MT Paul Moore (HP) - PM Bill O'Donnel (SGI) - BO Joe Nall Lisa Smith (HP) Irena Boverman (RH) - IB Linda Knippers (HP) - LK Larry Wilson (IBM) Kylene Hall (IBM) Kris Wilson (IBM) James Antill (RH) - JA Klaus Weidner (Atsec) Steve Grubb (RH) - SG Dan Walsh (RH) - DW Amy Smith (HP) Chad Hansen (TCS) Joy Latten (IBM) - JL Please forgive if anything was omitted or anyone's name was not captured. Tentative Agenda: Kernel / Beta / rawhide update SELinux base and MLS policy update PAM & VFS polyinstantiation CIPSO IPsec xinetd Self tests / aide Cron, tmpwatch, mail, etc. Bugs / remaining tasks Final cutoff date Bug Process =========== GW - We have to mirror to issue tracker, and this is a post beta process. This is for anything out of development. This is our agreed upon process. RH will decide if they become bugzilla IB - We want partners to use RHIT, but project managers are suggesting to do bugzilla. Make it public, then file an issue tracker. This prevents visibility issues and makes it easier to manage for RH. You can continue to use IT, but making bugzillas public which originated from IT is harder. GW - Is this an agreed upon process? IB - Yes GW - Great, we'll do this. So we would create 2 bugzillas? IB - Create RH bugzilla (via bugzilla.redhat.com) to get public entry. Then do regular process using your bugzilla and link against the public one. This is hard, but better than current process. GW - This is a deviation from our existing process. We were told opening direct bug a no-no. IB - I think we can meet requirements by having an IT bug point to a public bug. GW - So this should let everyone have visibility, and permit everyone to write bugs. I encourage people to write bugs when you see problems. IB - Remember to not mark them as private. Kernel / Beta / rawhide update ============================== GW - Install painpoint is virtual ethernet issue on ppc LPARs. This is bug is filed. There is the outstanding setrans.conf bug with the c255 not c1023 (also filed). LK - Having issue where can't create a user account someone can log into. First time someone logs in, passwd is accepted but connection is dropped. 2nd time the connection is completed, but you can't access the home directory. GW - Seeing messages in /var/log/secure? LK - Need to check that. Definitely am having problem with polyinstantiation. Still confused about how home directories are being created in the first place. Could be related to /tmp directories. MT - No bugs have been filed regarding these issues, but we have seen them. DW - 3 steps with semanage to create a user. Add user to get uid, semanage to link to staff user, and third step is to relabel home directory. LK - That might help, but I want to create a regular user. DW - You should just need to use useradd and the defaults should be ok (defaults to user_u). KW - Even with regular user with non-default levels, you need to use semanage to relabel home directory. LK - Seeing weird things on users are being created with kickstart script. First user is being created slightly differently than second user. Will compile some information on this. KW - Ok, not seen this... could be a problem with the tools. LK - Wasn't sure if the first semanage caused a policy reload, which could be causing the first/second user difference. DW - semanage will cause a policy reload. KW - It could be that the first user didn't have the policy loaded correctly. There is an open bugzilla about post-install section of the mls policy rpm not being run correctly. DW - OK, will look for that bug. One thing admin might want to do is automate these three steps with a simple shell script. Reason I hesitate to do that is to have admin understand the actions when adding a user. DW - Another thing found, when you create a file on the system, the user components of the file/diretory get assigned to the user who created. if you login with ssh, you get staff_u, if you login console, you get root:. Its consistant, but not expected. SG - This sounds like a bug. DW - Whats the bug. SG - user winds up in a state which conflicts with the relabel of the directory. If you did a restorecon, would that not correct it? DW - When doing restorecon, you're loosing who created the file, you set it to system defaults. LK - Still, someone's home directory does depend on who did the useradd. SG - Should be predictable, every time you do a relabel, its going to change. Me, I would think we should fix that so aide doesn't complain. DW - If you relabel, aide is going to complain. LK - I think i got a difference of behavior when adding a regular user. SG - Create users, run for two weeks, do a relabel, and they're labels change. JA - If you create a user and relabel directory immediately, aide won't care about its a short amount of time. SG - Seems to me when it creates home directory, it should query policy and get the context correct. LK - Just created a user directory, and the home dir has user staff_u but type userhome_dir_t. I agree with Steve, if we're going to create the home directory, we should create it with the context it is going to end up with. SG - I think we should get a bug against this. DW - I can argue the other side of that, but you're fixing a fundamental problem about how the system works... this will happen in other situations as well. This is how the user component of SELinux works. I hesitate because there are other ways to create the user's home diretory. Worried about polyinstantion, what does the user component have when the directory gets created? its a bigger problem than just useradd. LK - I know kickstart script calls useradd. SG - I guess we'll fix it in the obvious place and see where else it pops up. GW - Another thing we noticed was that trying to put system into single user mode fails. DW - Yeah, updated the policy (on my people page) to allow this. Will be in the beta. KW - mls policy rpm post-install RHIT 102563 SG - Did talking with people who do bugs, got a tentative agreement that bugs that have LSPP in the subject will get accelerated to engineering. IB - Steve, we've agreed that HP and IBM will file bugzillas directly and will then file RHIT and reference that bugzilla. This way bugzillas will stay public. This eliminates the escalation issue. GW - Any other issues with beta or lspp.55? Should we move to 55 kernel or use next beta kernel? SG - 55 has late breaking changes... not sure if they are integrated into beta kernel. Stay with 55 for the moment. BO - Question about lspp.55 kernel... been using lspp.51 for some time for a demo, but I got 55 this morning, and getpeercon on local ipsockets fail.... is that the expected behavior? CH - I believe the expected behaviour is getpeercon will only get a result when you have labeled networking. PM - getpeercon can only work when you are using labeled networking. BO - I don't know how to configure ipsec to use loopback... do you? CH - Venkat had a suggestion, but I don't know if anyone has tested it. The impression I got is the code is all there, just not tested. I know James Morris doesn't like that approach JL - I tried using getpeercon with regular ipsec, but I haven't tried it with labeled networking. I'll try with non-labeled and labeled. There was a sys-ctl had to use. CH - Really hard to implement with ipsec, other than sys-ctl variable, which for some reason, James does not like. GW - Why is it off? CH - Probably performance. Why would you want to do ipsec over localhost. If you want to know, dig up the threads in the archive. LK - After I run newrole to change roles, more doesn't work. I get one page. Getting an EBADFD when more tries to read more input. But this is only after doing a newrole. SELinux base and MLS policy update ================================== DW - No updates on base policy. Mostly all bug fixes at this point. Can get latest policy from my people page. GW - Will these be in the refresh? DW - Yes, either this coming or the one following. GW - Doing level selection testing, and on one of the tests I got a stack trace (double free corruption). Have a little matrix going of results. GW - Stack trace was from logging in with ordinary user from console, had default staff role, selected s0 as level, and got a stack dump. Trying to go through all combinations. SG - OK, does stack dump have debug information? Please forward to me. GW - Still haven't tried with ordinary user in enforcing mode. Done with root over console and ssh. root on the console seems to be what works in permissive mode, and I htink the only thing I've gotten to work correctly. I'll try the ordinary users over ssh. SG - What was in the pam stack? anything different from the default? GW - Not that I can see. Just put the selection keywork in the login, sshd and remote. JA - As Steve said, its something that is getting NULL'd out and freed. Could it have been out of his MLS allowed range? GW - Should have been. JA - If the range isn't allowed, it goes to an error path, which might be hitting the free. GW - Tried with translated and untranslated to see if that was the issue. This was untranslated. I'll send you the incomplete table. JA - yes, Please send to steve and me. We need to see if the range check failed. GW - OK, will send to you privately and will try to complete the matrix. JA - It would be good to find out if the MLS range check passed, because that would show the policy failing when it shouldn't be. GW - Yeah, used s0 and it has SystemLow-SystemHigh. PAM & VFS polyinstantiation =========================== < No more issues > CIPSO & IPsec ============= PM - CIPSO - no outstanding issues GW - ipsec, doing stress runs? JL - no, forgot. Will do tonight and do the localhost check. I think I sent out the policy to get ipsec to run in enforcing. Chris sent back comments, and we'll need to work on this a bit. Wondering if ipsec should be run as sysadm domain or should run in ipsec domain... chris thinks should run in ipsec domain. GW - Then we need transitions. JL - Already some transitiions, but we need to use it. Once we get that ironed out, we can make those changes. GW - Things working from an MLS pov? JL - yup. won't add SA unless in range of policy and all that kind of stuff. SG - Not seen patch for ipsec stuff... did you send that to net-dev? JL - Yeah, I tried to send it, but I haven't seen it yet. Steve, you should have a copy. SG - Didn't get it. JL - OK, will resend. xinetd ====== SG - No news, really close to working on it. Been spending time on audit getting it to final version so its ready. One more thing to fix, then starting working on xinetd. audit ===== SG - Going to put out 1.3 version of audit with lots of cleanup and tiny bug fixes. Fixes to auserach and things like that. Ability to get raw output out of auserach, so its in the same format as the audit log (no changes). You can also pipe that to aureport so you can do data processing. Self tests / aide ================= GW - Hacked on selftest, dan has given me more of a clue about what I should de doing. Dan, should I do the enable function and that will do the check? DW - The enable function does all the stuff we want the python stuff to do... Steve doesn't want people to check if the audit deamon is running and then sending the audit message because that pounds the hell out of the kernel. So there isn't an API to do that. GW - Aide doesn't seem to return a bad return code if the check fails. It just reports that it did the check. Will have to parse the output. JA - We should be able to fix that. You shouldn't be parsing the output. SG - There should be some discussion about what consitute a failure. If things get added or deleted, does that consitute a failure? GW - Well, that depends on if you wanted that to get added. deleted. I want a mode that returns a return code that says something changed. JA - Like --check? GW - Yeah. SG - We need to talk to upstream about that. Its something we just recently integrated. Aide itself will fire off an audit message if something has changed. GW - So do I look in audit log? I want to have a return code. Parsing seems unclean. SG - OK, we can just talk with the guys upstream. They might have overlooked it. GW - OK, can you talk to them? SG - yeah, I'll talk t them. Outstanding Issues ================== DW - Asked about MLS contraints being removed, TCS says they are required. KW - The right constriants? Seen response, but not read it in detail. If they are the way they are intended to be, then we need to understand why and we should have the documentation patched so they are better documented. JL - Klaus, while you are on, for labelec ipsec, the ability to toggle accepting labeled/ unlabeled is an LSPP requirement? KW - Doesn't need to be a toggle, but you can't be able to circumvent. Toggling isn't required, but being able to do so should be there. JL - So we do need the ability to toggle? KW - Doesn't need to be a run-time switch. Could be boot or even install. But that's not very useful. If you claim to enforce, there needs to be a way to do that. KW - What we don't want is to have the system accept both labeled and unlabeled by default. There is no requirement that you need to able to weaken (i.e. accept unlabeled). Users might like it , but its not required. GW - What is the difficulty of providing the toggle? JL - I need to post this to the mailing list. GW - We were thinking about a boolean in the policy which would reject unlabeled packets. JL - I wanted to know if we even needed to be able to do that. I'll send a reply to Venkat's post and ask what it would take to do that. From jantill at redhat.com Tue Nov 28 23:13:11 2006 From: jantill at redhat.com (James Antill) Date: Tue, 28 Nov 2006 18:13:11 -0500 Subject: [redhat-lspp] Xinetd patches for selinux context configuration Message-ID: <1164755591.18588.16.camel@code.and.org> I've created the patches to allow selinux context to be specified for xinetd and they seem to work, however one problem is that xinetd isn't allowed to transition to any other domains. Eg: type=AVC msg=audit(1164755336.496:24242): avc: denied { transition } for pid=22285 comm="xinetd" name="in.cat.msg" dev=md0 ino=7619116 scontext=user_u:system_r:inetd_t:s0 tcontext=user_u:system_r:httpd_t:s0 tclass=process type=AVC msg=audit(1164755097.924:24194): avc: denied { transition } for pid=21497 comm="xinetd" name="in.cat.msg" dev=md0 ino=7619116 scontext=user_u:system_r:inetd_t:s0 tcontext=user_u:system_r:inetd_t:s0-s0:c0.c1023 tclass=process type=AVC msg=audit(1164755203.968:24207): avc: denied { entrypoint } for pid=21825 comm="xinetd" name="in.cat.msg" dev=md0 ino=7619116 scontext=user_u:system_r:fingerd_t:s0 tcontext=user_u:object_r:httpd_exec_t:s0 tclass=file ...so either the setexeccon fails, because xinetd isn't allowed to transition to that context ... or the context doesn't have the ability to exec anything but itself (you can transition to fingerd_t and then exec fingerd_exec_t ... but that doesn't do anything). Example config.: # selinux_context = user_u:system_r:inetd_t:SystemLow-SystemHigh selinux_context = user_u:system_r:httpd_t # selinux_context = user_u:system_r:fingerd_t Anyway, here are the patches/rpms: http://people.redhat.com/jantill/xinetd/ -- James Antill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From paul.moore at hp.com Wed Nov 29 06:00:25 2006 From: paul.moore at hp.com (Paul Moore) Date: Wed, 29 Nov 2006 01:00:25 -0500 Subject: [redhat-lspp] Xinetd patches for selinux context configuration In-Reply-To: <1164755591.18588.16.camel@code.and.org> References: <1164755591.18588.16.camel@code.and.org> Message-ID: <200611290100.25530.paul.moore@hp.com> On Tuesday 28 November 2006 6:13 pm, James Antill wrote: > Example config.: > > # selinux_context = user_u:system_r:inetd_t:SystemLow-SystemHigh > selinux_context = user_u:system_r:httpd_t > # selinux_context = user_u:system_r:fingerd_t > > Anyway, here are the patches/rpms: > > http://people.redhat.com/jantill/xinetd/ I just took a quick look at the patch and I have to ask why you decided to take the context from the xinetd config file instead of using security_compute_create() as described in BZ #209379? As it stands I don't think the current approach of taking the full SELinux context (TE and MLS label) from the config file solves the problem we are interested in - multi-level network services via xinetd. Thanks for working on this. -- paul moore linux security @ hp From jantill at redhat.com Wed Nov 29 07:06:34 2006 From: jantill at redhat.com (James Antill) Date: Wed, 29 Nov 2006 02:06:34 -0500 Subject: [redhat-lspp] Xinetd patches for selinux context configuration In-Reply-To: <200611290100.25530.paul.moore@hp.com> References: <1164755591.18588.16.camel@code.and.org> <200611290100.25530.paul.moore@hp.com> Message-ID: <1164783994.18588.35.camel@code.and.org> On Wed, 2006-11-29 at 01:00 -0500, Paul Moore wrote: > I just took a quick look at the patch and I have to ask why you decided to > take the context from the xinetd config file instead of using > security_compute_create() as described in BZ #209379? As it stands I don't > think the current approach of taking the full SELinux context (TE and MLS > label) from the config file solves the problem we are interested in - > multi-level network services via xinetd. Ok, if that's the problem I'm not sure why we want any changes to the config. file. As I understand it from the above BZ, you have: user_u:system_r:inetd_t = xinetd is running as this user_u:system_r:fingerd_exec_t = in.fingerd on disk user_u:system_r:fingerd_t = in.fingerd when run normally from xinetd user_u:system_r:unconfined_t:SystemLow-SystemHigh = getpeercon() user_u:system_r:fingerd_t:SystemLow-SystemHigh = What we want the in.fingerd to be running in, with ML networking So we need to take the getfilecon() and getpeercon() and combine them somehow (the BZ says security_compute_create()[1]), and we might then need to move to fgetfilecon() / fexecve() to close the race :(. Is the above right? If not what piece(s) of information need to come from the config. file? [1] I tried a few different calls with security_compute_create, and maybe I'm not using the right security class, but I can't get it to combine the TE and MLS correctly. -- James Antill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From paul.moore at hp.com Wed Nov 29 13:17:15 2006 From: paul.moore at hp.com (Paul Moore) Date: Wed, 29 Nov 2006 08:17:15 -0500 Subject: [redhat-lspp] Xinetd patches for selinux context configuration In-Reply-To: <1164783994.18588.35.camel@code.and.org> References: <1164755591.18588.16.camel@code.and.org> <200611290100.25530.paul.moore@hp.com> <1164783994.18588.35.camel@code.and.org> Message-ID: <200611290817.15730.paul.moore@hp.com> On Wednesday 29 November 2006 2:06 am, James Antill wrote: > On Wed, 2006-11-29 at 01:00 -0500, Paul Moore wrote: > > I just took a quick look at the patch and I have to ask why you decided > > to take the context from the xinetd config file instead of using > > security_compute_create() as described in BZ #209379? As it stands I > > don't think the current approach of taking the full SELinux context (TE > > and MLS label) from the config file solves the problem we are interested > > in - multi-level network services via xinetd. > > Ok, if that's the problem I'm not sure why we want any changes to the > config. file. As I understand it from the above BZ, you have: > > user_u:system_r:inetd_t > = xinetd is running as this > user_u:system_r:fingerd_exec_t > = in.fingerd on disk > user_u:system_r:fingerd_t > = in.fingerd when run normally from xinetd > user_u:system_r:unconfined_t:SystemLow-SystemHigh > = getpeercon() > > user_u:system_r:fingerd_t:SystemLow-SystemHigh > = What we want the in.fingerd to be running in, with ML networking That's it exactly. I don't think we want any changes to the config file, at least I don't see a need for any changes; I think all we want is a change to how xinetd operates when the "LABELED" flag is specified. > So we need to take the getfilecon() and getpeercon() and combine them > somehow (the BZ says security_compute_create()[1]), and we might then > need to move to fgetfilecon() / fexecve() to close the race :(. > Is the above right? If not what piece(s) of information need to come > from the config. file? > > [1] I tried a few different calls with security_compute_create, and > maybe I'm not using the right security class, but I can't get it to > combine the TE and MLS correctly. Granted I haven't actually tried any of this to verify that it works, but I suspect you would want to do the following (I'm also not the best person to ask about SELinux userspace calls so there may be better functions to use): 1. getpeercon() to determine the context of the remote 2. getcon() to determine the context of xinetd 3. getfilecon() to determine the context of the server's binary 4. Compute the context of the server's domain when run by xinetd using security_compute_create(), the contexts from #2 and #3, and the process class 5. Replace the MLS label from #4 with the MLS label from #1 6. setexeccon() with #5 to set the context for the server 7. Start the server Yes, there is a race condition between steps #3 and #7 but in practice I don't think it will be a real issue as normal users should not have write/relabel access to any of the server's binaries on disk which means only the admin would have the ability to cause the race. -- paul moore linux security @ hp From cpebenito at tresys.com Wed Nov 29 14:59:31 2006 From: cpebenito at tresys.com (Christopher J. PeBenito) Date: Wed, 29 Nov 2006 09:59:31 -0500 Subject: [redhat-lspp] Re: labeled ipsec policy In-Reply-To: <1164660680.17737.459.camel@faith.austin.ibm.com> References: <1163802623.17737.398.camel@faith.austin.ibm.com> <1164118202.12234.24.camel@sgc> <1164660680.17737.459.camel@faith.austin.ibm.com> Message-ID: <1164812372.25344.41.camel@sgc> On Mon, 2006-11-27 at 14:51 -0600, Joy Latten wrote: > On Tue, 2006-11-21 at 09:10 -0500, Christopher J. PeBenito wrote: > > On Fri, 2006-11-17 at 16:30 -0600, Joy Latten wrote: > > > The following policy enables labeled ipsec to run > > > in enforcing mode. I configure labeled ipsec in sysadm_r role. > > > Thus the rules I needed were specific to this role. > > [cut] > > > Included are some interfaces, which I used in an xxxx.if > > > file. Then, there are a bunch of rules which I used in a xxxx.te file > > > These rules were just an example of what I needed > > > to get ping, nc, and ssh to work with labeled ipsec. For my > > > policy, I used the types unlabeled_t, passwd_t, and ipsec_spd_t. > > > When using passwd_t, ipsec_spd_t or any other domain, please be > > > mindful of mls constraints. > > [cut] > > > interface(`ipsec_set_label',` > > > gen_require(` > > > type sysadm_t; > > > ') > > > > > > allow sysadm_t $1:association setcontext; > > > ') > > > > Interfaces are written from the perspective of the subject (except for a > > few very specific cases), so the parameter should be the subject, not > > the object. Neglecting that, is this for sysadm_t instead of > > ipsec_mgmt_t? I suspect that we want to add an interface to the domain > > module that allows setcontext on the domain attribute. > > Yes, this was for sysadm_t. I had taken a look at the current ipsec.if, > ipsec.te, ipsec.fc and userdomain.te files as well and had wondered why > we were not executing ipsec in the ipsec domain. It seem that the policy > in those files was more for pluto and its utilities than ipsec-tools' > utilities. > > So should racoon and setkey, the ipsec-tools' utiltites, be run in the > ipsec domain? Should the sysadm_r role only be allowed to configure > ipsec? I don't know all the little details of racoon and setkey, but I think racoon would run in ipsec_t and setkey in ipsec_mgmt_t. However, if the policy is going to be overhauled, then racoon_t and setkey_t seem more applicable. Then we can just add aliases for compatibility. For the non-MLS strict policy, sysadm should be able to run setkey. For MLS, I'd have to defer that to someone who knows if there are any relevant LSPP requirements for this. > > > interface(`ipsec_label_sa_pol',` > > > allow $1 $2:association polmatch; > > > ') > > > > Generally refpolicy would leave this as a raw rule these types are in > > separate modules, in which case the interface would be in $2's module > > and have a specific type instead of $2. > > Ok, I think I understand what you mean. From what I can tell of the code > for the "polmatch" permission, $2 will most likely always be the type of > the security context in the ipsec policy. However, this could be set to > anything by the sysadm. Should I setup a default? For example, assume > labeled ipsec policy to have a type of ipsec_spd_t? Thus a sysadm who > decides to use labels in his ipsec policy, by default could use > ipsec_spd_t for the type and specify whatever he/she wants for the mls > level. Then he/she would use the interface to say which domains he wants > to allow to "polmatch" to this. Does this sound reasonable? If so, I'll > make the change and also make sure this is documented. I'm not very sure how users will use the SPD labeling. I suspect that they will be labeled with probably the other side's domain type. For example, if httpd_t and mozilla_t are connected, the SPD would be mozilla_t on the http machine and httpd_t on the mozilla machine. > > > interface(`ipsec_labels_send_recv',` > > > allow $1 self:association { recvfrom sendto }; > > > ') > > > > This would be raw rule in refpolicy instead of an interface. > > I am not too sure I understand. We need a rule allowing flow->sid to use > SA's sid to send. SA's type as well as flow's type will be that of the > socket. Thus it could be any application or daemon. Do I need to add > this rule to every daemon/application as a raw rule? For example, in > netutils.te, add this for ping? In general, the network access needs to be specified in each of the modules, just like all the socket, node, netif, etc already specified in the modules. For the send side, it also brings back to the question of if the sendto check is needed, since it is always checked against self. But that assumes there isn't a use case for being able to receive but not send on labeled connections. I don't have any strong indication either way, except that netlabel only has a recvfrom check. For the receive side, there is going to have to be an interface, for example interface(`apache_recvfrom',` allow $1 apache_t:association recvfrom; ') and then you might see apache_recvfrom(mozilla_t) If the sendto check stays, we could conceivably add this to the above interface: allow $1 self:association sendto; > > > interface(`ipsec_tools_utilities',` > > > gen_require(` > > > type isakmp_port_t; > > > type inaddr_any_node_t; > > > ') > > > > > > # allow setkey and racoon to create and use a key socket. > > > allow $1 self:key_socket { create read write setopt }; > > > > > > # allow racoon to use ISAKMP port > > > allow $1 isakmp_port_t:udp_socket name_bind; > > > > > > # allow racoon to use avc_has_perm in within_range() > > > # to determine if proposed SA "polmatches" to policy > > > allow $1 self:netlink_selinux_socket { bind create read }; > > > > > > # I think this is so racoon can listen on an admin port. > > > allow $1 inaddr_any_node_t:tcp_socket node_bind; > > > > > > # to create, remove read lock in /var/racoon/ > > > ipsec_manage_pid($1) > > > > > > # in grabmyaddrs() socket(PF_ROUTE...) > > > allow $1 self:netlink_route_socket { create_netlink_socket_perms }; > > > ') > > > > Again, why is this needed, instead of ipsec_mgmt_t? > > > > I suspect that the ipsec policy needs to be overhauled because I believe > > it was oriented towards the KAME ipsec implementation (pluto, et al) and > > was augmented to work with racoon afterwards. > > I think you are correct. > > Right now racoon and setkey use ipsec_exec_t domain. Is this ok or > should it be ipsec_mgmt_t? Also, should I go ahead and make the > modifications for racoon and setkey to run in the ipsec domain (either > ipsec_exec_t or ipsec_mgmt_t) instead of sysadm_t domain ? I wouldn't > mind making an attempt at it with your help and as long as I knew you > would review it for me. See my above comments. -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 From sds at tycho.nsa.gov Wed Nov 29 15:31:37 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 29 Nov 2006 10:31:37 -0500 Subject: [redhat-lspp] Xinetd patches for selinux context configuration In-Reply-To: <200611290817.15730.paul.moore@hp.com> References: <1164755591.18588.16.camel@code.and.org> <200611290100.25530.paul.moore@hp.com> <1164783994.18588.35.camel@code.and.org> <200611290817.15730.paul.moore@hp.com> Message-ID: <1164814297.23019.152.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-11-29 at 08:17 -0500, Paul Moore wrote: > On Wednesday 29 November 2006 2:06 am, James Antill wrote: > > On Wed, 2006-11-29 at 01:00 -0500, Paul Moore wrote: > > > I just took a quick look at the patch and I have to ask why you decided > > > to take the context from the xinetd config file instead of using > > > security_compute_create() as described in BZ #209379? As it stands I > > > don't think the current approach of taking the full SELinux context (TE > > > and MLS label) from the config file solves the problem we are interested > > > in - multi-level network services via xinetd. > > > > Ok, if that's the problem I'm not sure why we want any changes to the > > config. file. As I understand it from the above BZ, you have: > > > > user_u:system_r:inetd_t > > = xinetd is running as this > > user_u:system_r:fingerd_exec_t > > = in.fingerd on disk > > user_u:system_r:fingerd_t > > = in.fingerd when run normally from xinetd > > user_u:system_r:unconfined_t:SystemLow-SystemHigh > > = getpeercon() > > > > user_u:system_r:fingerd_t:SystemLow-SystemHigh > > = What we want the in.fingerd to be running in, with ML networking > > That's it exactly. I don't think we want any changes to the config file, at > least I don't see a need for any changes; I think all we want is a change to > how xinetd operates when the "LABELED" flag is specified. > > > So we need to take the getfilecon() and getpeercon() and combine them > > somehow (the BZ says security_compute_create()[1]), and we might then > > need to move to fgetfilecon() / fexecve() to close the race :(. > > Is the above right? If not what piece(s) of information need to come > > from the config. file? > > > > [1] I tried a few different calls with security_compute_create, and > > maybe I'm not using the right security class, but I can't get it to > > combine the TE and MLS correctly. > > Granted I haven't actually tried any of this to verify that it works, but I > suspect you would want to do the following (I'm also not the best person to > ask about SELinux userspace calls so there may be better functions to use): > > 1. getpeercon() to determine the context of the remote > 2. getcon() to determine the context of xinetd > 3. getfilecon() to determine the context of the server's binary > 4. Compute the context of the server's domain when run by xinetd using > security_compute_create(), the contexts from #2 and #3, and the process > class > 5. Replace the MLS label from #4 with the MLS label from #1 > 6. setexeccon() with #5 to set the context for the server > 7. Start the server > > Yes, there is a race condition between steps #3 and #7 but in practice I don't > think it will be a real issue as normal users should not have write/relabel > access to any of the server's binaries on disk which means only the admin > would have the ability to cause the race. The above sounds correct. With regard to the "race", if the binary's type has changed since #3, then the execve should fail because the new domain computed by #4 will lack entrypoint permission to the new file type. -- Stephen Smalley National Security Agency From paul.moore at hp.com Wed Nov 29 18:54:48 2006 From: paul.moore at hp.com (Paul Moore) Date: Wed, 29 Nov 2006 13:54:48 -0500 Subject: [redhat-lspp] A quick HOW-TO on using the new CIPSO tag types Message-ID: <456DD778.9080500@hp.com> I just posted a set of patches to the netdev and SELinux mailing lists which add two new CIPSO tag types from the IETF draft. These two new types allow you to transmit categories greater than 240. See the draft for details: * http://sourceforge.net/docman/display_doc.php?docid=34650&group_id=174379 For those of you who want to play with the patches you can do so with the netlabel_tools you currently have; the only change is that instead of always specifying "tags:1" when adding a CIPSO DOI definition you can now use tag types "2" and "5", or a combination. Examples below: * Create a DOI definition using the enumerated tag type # netlabelctl cipsov4 add pass doi:1 tags:2 * Create a DOI definition using the ranged tag type # netlabelctl cipsov4 add pass doi:1 tags:5 * Create a DOI definition using multiple tag types # netlabelctl cipsov4 add pass doi:1 tags:2,5,1 When you specify multiple tag types for a DOI definition NetLabel gives precedence to the types based on the order in which you supplied them on the command line. In the example above, "tags:2,5,1", NetLabel will first try to use tag type "2", then type "5", and finally type "1"; as before, if the MLS label can not be represented using the current configuration the socket will not be created. -- paul moore linux security @ hp From dwalsh at redhat.com Wed Nov 29 18:59:40 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 29 Nov 2006 13:59:40 -0500 Subject: [redhat-lspp] /tmp polyinstantiation and the man command In-Reply-To: <1164736475.23019.12.camel@moss-spartans.epoch.ncsc.mil> References: <456B78DA.4010909@hp.com> <1164719365.13758.250.camel@moss-spartans.epoch.ncsc.mil> <456C5897.4050708@hp.com> <1164728602.23019.1.camel@moss-spartans.epoch.ncsc.mil> <456C5D69.5040201@hp.com> <1164736475.23019.12.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <456DD89C.10805@redhat.com> Stephen Smalley wrote: > On Tue, 2006-11-28 at 11:01 -0500, Linda Knippers wrote: > >> Stephen Smalley wrote: >> >>> On Tue, 2006-11-28 at 10:41 -0500, Linda Knippers wrote: >>> >>> >>>> Stephen Smalley wrote: >>>> >>>> >>>> >>>>> Version of policycoreutils-newrole and selinux-policy-mls? >>>>> Contents of /etc/pam.d/newrole? >>>>> >>>> Sorry, I'd mentioned in the call that I was running the latest from >>>> Dan's people page but omitted it from the mail. I have these >>>> rpms. >>>> >>>> policycoreutils-1.33.2-2.el5 >>>> policycoreutils-newrole-1.33.2-2.el5 >>>> selinux-policy-mls-2.4.5-3.el5 >>>> selinux-policy-2.4.5-3.el5 >>>> >>>> /etc/pam.d/newrole has this: >>>> #%PAM-1.0 >>>> auth include system-auth >>>> account include system-auth >>>> password include system-auth >>>> session include system-auth >>>> session optional pam_xauth.so >>>> >>> I would have expected the latter to include: >>> session required pam_namespace.so unmnt_remnt no_unmount_on_close >>> >> I added that line but I don't see any difference in behavior. I added >> it at the end. Does the location matter? (Sorry for the dumb pam question). >> > > Possibly, e.g. if there is a sufficient or requisite module in the > system-auth stack. Easiest thing to do is to move it up to the first > one and try again. But now I am wondering whether that policycoreutils > was built with LSPP_PRIV=y, which is required to enable the audit and > namespace functionality. The fedora devel .spec file still has > LOG_AUDIT_PRIV=y, which was the old flag for building with audit support > and no longer is used. > > ls -l /usr/bin/newrole > 1.33.5-4 > It does not. Fixed in 1.33.5-4 From jantill at redhat.com Wed Nov 29 19:04:17 2006 From: jantill at redhat.com (James Antill) Date: Wed, 29 Nov 2006 14:04:17 -0500 Subject: [redhat-lspp] Xinetd patches for selinux context configuration In-Reply-To: <1164814297.23019.152.camel@moss-spartans.epoch.ncsc.mil> References: <1164755591.18588.16.camel@code.and.org> <200611290100.25530.paul.moore@hp.com> <1164783994.18588.35.camel@code.and.org> <200611290817.15730.paul.moore@hp.com> <1164814297.23019.152.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1164827057.18588.44.camel@code.and.org> On Wed, 2006-11-29 at 10:31 -0500, Stephen Smalley wrote: > On Wed, 2006-11-29 at 08:17 -0500, Paul Moore wrote: > > On Wednesday 29 November 2006 2:06 am, James Antill wrote: > > > On Wed, 2006-11-29 at 01:00 -0500, Paul Moore wrote: > > > > I just took a quick look at the patch and I have to ask why you decided > > > > to take the context from the xinetd config file instead of using > > > > security_compute_create() as described in BZ #209379? As it stands I > > > > don't think the current approach of taking the full SELinux context (TE > > > > and MLS label) from the config file solves the problem we are interested > > > > in - multi-level network services via xinetd. > > > > > > Ok, if that's the problem I'm not sure why we want any changes to the > > > config. file. As I understand it from the above BZ, you have: > > > > > > user_u:system_r:inetd_t > > > = xinetd is running as this > > > user_u:system_r:fingerd_exec_t > > > = in.fingerd on disk > > > user_u:system_r:fingerd_t > > > = in.fingerd when run normally from xinetd > > > user_u:system_r:unconfined_t:SystemLow-SystemHigh > > > = getpeercon() > > > > > > user_u:system_r:fingerd_t:SystemLow-SystemHigh > > > = What we want the in.fingerd to be running in, with ML networking > > > > That's it exactly. I don't think we want any changes to the config file, at > > least I don't see a need for any changes; I think all we want is a change to > > how xinetd operates when the "LABELED" flag is specified. > > > > > So we need to take the getfilecon() and getpeercon() and combine them > > > somehow (the BZ says security_compute_create()[1]), and we might then > > > need to move to fgetfilecon() / fexecve() to close the race :(. > > > Is the above right? If not what piece(s) of information need to come > > > from the config. file? > > > > > > [1] I tried a few different calls with security_compute_create, and > > > maybe I'm not using the right security class, but I can't get it to > > > combine the TE and MLS correctly. > > > > Granted I haven't actually tried any of this to verify that it works, but I > > suspect you would want to do the following (I'm also not the best person to > > ask about SELinux userspace calls so there may be better functions to use): > > > > 1. getpeercon() to determine the context of the remote > > 2. getcon() to determine the context of xinetd > > 3. getfilecon() to determine the context of the server's binary > > 4. Compute the context of the server's domain when run by xinetd using > > security_compute_create(), the contexts from #2 and #3, and the process > > class > > 5. Replace the MLS label from #4 with the MLS label from #1 > > 6. setexeccon() with #5 to set the context for the server > > 7. Start the server > > > > Yes, there is a race condition between steps #3 and #7 but in practice I don't > > think it will be a real issue as normal users should not have write/relabel > > access to any of the server's binaries on disk which means only the admin > > would have the ability to cause the race. > > The above sounds correct. With regard to the "race", if the binary's > type has changed since #3, then the execve should fail because the new > domain computed by #4 will lack entrypoint permission to the new file > type. Ok, I assume you still also want the MLS range to be configurably bound as in: http://www.redhat.com/archives/redhat-lspp/2005-September/msg00125.html ...I'm also having problems working out what to call security_compute_create() with. For instance I assumed this was right: security_context_t ret = NULL; if (security_compute_create("user_u:system_r:inetd_t:SystemLow-SystemHigh", "user_u:system_r:fingerd_exec_t", PROCESS__DYNTRANSITION, &ret) != -1) puts(ret); ...but it returns -1. It also has weird results is I pass other things in (role likes to change to object_r and MLS goes missing). One simple fix is to have the full context specified in the config. file, as it was in my first attempt ... but then take the MLS from the other end, if it passes a CONTEXT__CONTAINS check. Much like the crond/PAM changes. -- James Antill - setsockopt(fd, IPPROTO_TCP, TCP_CONGESTION, ...); setsockopt(fd, IPPROTO_TCP, TCP_DEFER_ACCEPT, ...); setsockopt(fd, SOL_SOCKET, SO_ATTACH_FILTER, ...); -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dwalsh at redhat.com Wed Nov 29 19:06:58 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 29 Nov 2006 14:06:58 -0500 Subject: [redhat-lspp] /tmp polyinstantiation and the man command In-Reply-To: <456DD89C.10805@redhat.com> References: <456B78DA.4010909@hp.com> <1164719365.13758.250.camel@moss-spartans.epoch.ncsc.mil> <456C5897.4050708@hp.com> <1164728602.23019.1.camel@moss-spartans.epoch.ncsc.mil> <456C5D69.5040201@hp.com> <1164736475.23019.12.camel@moss-spartans.epoch.ncsc.mil> <456DD89C.10805@redhat.com> Message-ID: <456DDA52.5040702@redhat.com> Daniel J Walsh wrote: > Stephen Smalley wrote: >> On Tue, 2006-11-28 at 11:01 -0500, Linda Knippers wrote: >> >>> Stephen Smalley wrote: >>> >>>> On Tue, 2006-11-28 at 10:41 -0500, Linda Knippers wrote: >>>> >>>> >>>>> Stephen Smalley wrote: >>>>> >>>>> >>>>> >>>>>> Version of policycoreutils-newrole and selinux-policy-mls? >>>>>> Contents of /etc/pam.d/newrole? >>>>>> >>>>> Sorry, I'd mentioned in the call that I was running the latest from >>>>> Dan's people page but omitted it from the mail. I have these >>>>> rpms. >>>>> >>>>> policycoreutils-1.33.2-2.el5 >>>>> policycoreutils-newrole-1.33.2-2.el5 >>>>> selinux-policy-mls-2.4.5-3.el5 >>>>> selinux-policy-2.4.5-3.el5 >>>>> >>>>> /etc/pam.d/newrole has this: >>>>> #%PAM-1.0 >>>>> auth include system-auth >>>>> account include system-auth >>>>> password include system-auth >>>>> session include system-auth >>>>> session optional pam_xauth.so >>>>> >>>> I would have expected the latter to include: >>>> session required pam_namespace.so unmnt_remnt >>>> no_unmount_on_close >>>> >>> I added that line but I don't see any difference in behavior. I added >>> it at the end. Does the location matter? (Sorry for the dumb pam >>> question). >>> >> >> Possibly, e.g. if there is a sufficient or requisite module in the >> system-auth stack. Easiest thing to do is to move it up to the first >> one and try again. But now I am wondering whether that policycoreutils >> was built with LSPP_PRIV=y, which is required to enable the audit and >> namespace functionality. The fedora devel .spec file still has >> LOG_AUDIT_PRIV=y, which was the old flag for building with audit support >> and no longer is used. >> >> ls -l /usr/bin/newrole >> 1.33.5-4 >> > It does not. Fixed in 1.33.5-4 > > > -- > redhat-lspp mailing list > redhat-lspp at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-lspp policycoreutils-1.33.5-4 is available on http://people.redhat.com/dwalsh/SELinux/RHEL5 From eparis at redhat.com Wed Nov 29 19:21:02 2006 From: eparis at redhat.com (Eric Paris) Date: Wed, 29 Nov 2006 14:21:02 -0500 Subject: [redhat-lspp] A quick HOW-TO on using the new CIPSO tag types In-Reply-To: <456DD778.9080500@hp.com> References: <456DD778.9080500@hp.com> Message-ID: <1164828062.2079.73.camel@localhost.localdomain> On Wed, 2006-11-29 at 13:54 -0500, Paul Moore wrote: > I just posted a set of patches to the netdev and SELinux mailing lists which add > two new CIPSO tag types from the IETF draft. These two new types allow you to > transmit categories greater than 240. See the draft for details: > > * http://sourceforge.net/docman/display_doc.php?docid=34650&group_id=174379 > > For those of you who want to play with the patches you can do so with the > netlabel_tools you currently have; the only change is that instead of always > specifying "tags:1" when adding a CIPSO DOI definition you can now use tag types > "2" and "5", or a combination. Examples below: As of right now I do not foresee this going into RHEL5 GA and thus would not be part of the current LSPP certification. It's possible that such a patch could make U1 but that would be too late for certification. So I'm not sure how this howto is applicable to the LSPP effort underway. This howto will clearly be of interest when we do the RHEL6 lspp effort some day down the line. If I'm misunderstanding what is needed to meet LSPP and this is somehow required please let me know so we can talk about what needs to be done. -Eric From sds at tycho.nsa.gov Wed Nov 29 19:22:06 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 29 Nov 2006 14:22:06 -0500 Subject: [redhat-lspp] Xinetd patches for selinux context configuration In-Reply-To: <1164827057.18588.44.camel@code.and.org> References: <1164755591.18588.16.camel@code.and.org> <200611290100.25530.paul.moore@hp.com> <1164783994.18588.35.camel@code.and.org> <200611290817.15730.paul.moore@hp.com> <1164814297.23019.152.camel@moss-spartans.epoch.ncsc.mil> <1164827057.18588.44.camel@code.and.org> Message-ID: <1164828126.23019.239.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-11-29 at 14:04 -0500, James Antill wrote: > On Wed, 2006-11-29 at 10:31 -0500, Stephen Smalley wrote: > > On Wed, 2006-11-29 at 08:17 -0500, Paul Moore wrote: > > > On Wednesday 29 November 2006 2:06 am, James Antill wrote: > > > > On Wed, 2006-11-29 at 01:00 -0500, Paul Moore wrote: > > > > > I just took a quick look at the patch and I have to ask why you decided > > > > > to take the context from the xinetd config file instead of using > > > > > security_compute_create() as described in BZ #209379? As it stands I > > > > > don't think the current approach of taking the full SELinux context (TE > > > > > and MLS label) from the config file solves the problem we are interested > > > > > in - multi-level network services via xinetd. > > > > > > > > Ok, if that's the problem I'm not sure why we want any changes to the > > > > config. file. As I understand it from the above BZ, you have: > > > > > > > > user_u:system_r:inetd_t > > > > = xinetd is running as this > > > > user_u:system_r:fingerd_exec_t > > > > = in.fingerd on disk > > > > user_u:system_r:fingerd_t > > > > = in.fingerd when run normally from xinetd > > > > user_u:system_r:unconfined_t:SystemLow-SystemHigh > > > > = getpeercon() > > > > > > > > user_u:system_r:fingerd_t:SystemLow-SystemHigh > > > > = What we want the in.fingerd to be running in, with ML networking > > > > > > That's it exactly. I don't think we want any changes to the config file, at > > > least I don't see a need for any changes; I think all we want is a change to > > > how xinetd operates when the "LABELED" flag is specified. > > > > > > > So we need to take the getfilecon() and getpeercon() and combine them > > > > somehow (the BZ says security_compute_create()[1]), and we might then > > > > need to move to fgetfilecon() / fexecve() to close the race :(. > > > > Is the above right? If not what piece(s) of information need to come > > > > from the config. file? > > > > > > > > [1] I tried a few different calls with security_compute_create, and > > > > maybe I'm not using the right security class, but I can't get it to > > > > combine the TE and MLS correctly. > > > > > > Granted I haven't actually tried any of this to verify that it works, but I > > > suspect you would want to do the following (I'm also not the best person to > > > ask about SELinux userspace calls so there may be better functions to use): > > > > > > 1. getpeercon() to determine the context of the remote > > > 2. getcon() to determine the context of xinetd > > > 3. getfilecon() to determine the context of the server's binary > > > 4. Compute the context of the server's domain when run by xinetd using > > > security_compute_create(), the contexts from #2 and #3, and the process > > > class > > > 5. Replace the MLS label from #4 with the MLS label from #1 > > > 6. setexeccon() with #5 to set the context for the server > > > 7. Start the server > > > > > > Yes, there is a race condition between steps #3 and #7 but in practice I don't > > > think it will be a real issue as normal users should not have write/relabel > > > access to any of the server's binaries on disk which means only the admin > > > would have the ability to cause the race. > > > > The above sounds correct. With regard to the "race", if the binary's > > type has changed since #3, then the execve should fail because the new > > domain computed by #4 will lack entrypoint permission to the new file > > type. > > Ok, I assume you still also want the MLS range to be configurably bound > as in: > > http://www.redhat.com/archives/redhat-lspp/2005-September/msg00125.html Yes, although one might be able to handle that in the labeled networking code itself, by rejecting packets with labels outside of the client host's authorized range before they are ever received by userspace. > ...I'm also having problems working out what to call > security_compute_create() with. See the runcon source in coreutils or rpm_execcon() in libselinux. > For instance I assumed this was right: > > security_context_t ret = NULL; > if (security_compute_create("user_u:system_r:inetd_t:SystemLow-SystemHigh", Correct - the current context of the subject. > "user_u:system_r:fingerd_exec_t", Not quite - this should be an object context; you should have used object_r above. > PROCESS__DYNTRANSITION, Completely wrong - this should be a security class value, not a permission value. In particular, SECCLASS_PROCESS. > &ret) != -1) < 0 is more general. > puts(ret); > > ...but it returns -1. That's because the inputs were invalid. -- Stephen Smalley National Security Agency From paul.moore at hp.com Wed Nov 29 19:32:36 2006 From: paul.moore at hp.com (Paul Moore) Date: Wed, 29 Nov 2006 14:32:36 -0500 Subject: [redhat-lspp] A quick HOW-TO on using the new CIPSO tag types In-Reply-To: <1164828062.2079.73.camel@localhost.localdomain> References: <456DD778.9080500@hp.com> <1164828062.2079.73.camel@localhost.localdomain> Message-ID: <456DE054.5010907@hp.com> Eric Paris wrote: > On Wed, 2006-11-29 at 13:54 -0500, Paul Moore wrote: > >>I just posted a set of patches to the netdev and SELinux mailing lists which add >>two new CIPSO tag types from the IETF draft. These two new types allow you to >>transmit categories greater than 240. See the draft for details: >> >> * http://sourceforge.net/docman/display_doc.php?docid=34650&group_id=174379 >> >>For those of you who want to play with the patches you can do so with the >>netlabel_tools you currently have; the only change is that instead of always >>specifying "tags:1" when adding a CIPSO DOI definition you can now use tag types >>"2" and "5", or a combination. Examples below: > > As of right now I do not foresee this going into RHEL5 GA and thus would > not be part of the current LSPP certification. It's possible that such > a patch could make U1 but that would be too late for certification. So > I'm not sure how this howto is applicable to the LSPP effort underway. > This howto will clearly be of interest when we do the RHEL6 lspp effort > some day down the line. If I'm misunderstanding what is needed to meet > LSPP and this is somehow required please let me know so we can talk > about what needs to be done. I posted the how-to on the LSPP mailing list because this has become the place where most MLS discussions take place, regardless of whether or not they are related to the current LSPP efforts of RH, HP, IBM, etc. I do not expect the latest patches to be included in RHEL5; I submitted the patches and the how-to because life goes on outside the evaluation ... and, well, it's more fun than the other things I have to work on :) In the future I can post these things elsewhere if it cuts down on the confusion? -- paul moore linux security @ hp From linda.knippers at hp.com Wed Nov 29 19:41:02 2006 From: linda.knippers at hp.com (Linda Knippers) Date: Wed, 29 Nov 2006 14:41:02 -0500 Subject: [redhat-lspp] A quick HOW-TO on using the new CIPSO tag types In-Reply-To: <456DE054.5010907@hp.com> References: <456DD778.9080500@hp.com> <1164828062.2079.73.camel@localhost.localdomain> <456DE054.5010907@hp.com> Message-ID: <456DE24E.5000105@hp.com> Paul Moore wrote: > In the future I can post these things elsewhere if it cuts down on the confusion? Maybe just be clear on what the target is. If the patches you've posted recently are for 2.6.20 and not for RHEL5, just let folks know that. I didn't look at the document yet so maybe it says that there. -- ljk From sds at tycho.nsa.gov Wed Nov 29 19:40:12 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 29 Nov 2006 14:40:12 -0500 Subject: [redhat-lspp] A quick HOW-TO on using the new CIPSO tag types In-Reply-To: <456DE054.5010907@hp.com> References: <456DD778.9080500@hp.com> <1164828062.2079.73.camel@localhost.localdomain> <456DE054.5010907@hp.com> Message-ID: <1164829212.23019.243.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-11-29 at 14:32 -0500, Paul Moore wrote: > Eric Paris wrote: > > On Wed, 2006-11-29 at 13:54 -0500, Paul Moore wrote: > > > >>I just posted a set of patches to the netdev and SELinux mailing lists which add > >>two new CIPSO tag types from the IETF draft. These two new types allow you to > >>transmit categories greater than 240. See the draft for details: > >> > >> * http://sourceforge.net/docman/display_doc.php?docid=34650&group_id=174379 > >> > >>For those of you who want to play with the patches you can do so with the > >>netlabel_tools you currently have; the only change is that instead of always > >>specifying "tags:1" when adding a CIPSO DOI definition you can now use tag types > >>"2" and "5", or a combination. Examples below: > > > > As of right now I do not foresee this going into RHEL5 GA and thus would > > not be part of the current LSPP certification. It's possible that such > > a patch could make U1 but that would be too late for certification. So > > I'm not sure how this howto is applicable to the LSPP effort underway. > > This howto will clearly be of interest when we do the RHEL6 lspp effort > > some day down the line. If I'm misunderstanding what is needed to meet > > LSPP and this is somehow required please let me know so we can talk > > about what needs to be done. > > I posted the how-to on the LSPP mailing list because this has become the place > where most MLS discussions take place, regardless of whether or not they are > related to the current LSPP efforts of RH, HP, IBM, etc. I do not expect the > latest patches to be included in RHEL5; I submitted the patches and the how-to > because life goes on outside the evaluation ... and, well, it's more fun than > the other things I have to work on :) > > In the future I can post these things elsewhere if it cuts down on the confusion? I'd favor pushing as much as possible over to selinux list (as long as it is germane to the upstream selinux project, which this is). Not everyone involved in selinux follows redhat-lspp, and at times this has led to serious disconnects. -- Stephen Smalley National Security Agency From sgrubb at redhat.com Wed Nov 29 19:52:38 2006 From: sgrubb at redhat.com (Steve Grubb) Date: Wed, 29 Nov 2006 14:52:38 -0500 Subject: [redhat-lspp] A quick HOW-TO on using the new CIPSO tag types In-Reply-To: <1164829212.23019.243.camel@moss-spartans.epoch.ncsc.mil> References: <456DD778.9080500@hp.com> <456DE054.5010907@hp.com> <1164829212.23019.243.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200611291452.38784.sgrubb@redhat.com> On Wednesday 29 November 2006 14:40, Stephen Smalley wrote: > ?Not everyone involved in selinux follows redhat-lspp, and at times this has > led to serious disconnects. At the same time, the selinux mail list has so much traffic that things can get lost there, too. In a way, I wished the selinux mail list was split into policy, devel, and user support. -Steve From vyekkirala at trustedcs.com Wed Nov 29 20:42:23 2006 From: vyekkirala at trustedcs.com (Venkat Yekkirala) Date: Wed, 29 Nov 2006 14:42:23 -0600 Subject: [redhat-lspp] Re: labeled ipsec policy In-Reply-To: <1164812372.25344.41.camel@sgc> Message-ID: <001701c713f6$e02b11b0$cc0a010a@tcssec.com> > I'm not very sure how users will use the SPD labeling. I suspect that > they will be labeled with probably the other side's domain type. For > example, if httpd_t and mozilla_t are connected, the SPD would be > mozilla_t on the http machine and httpd_t on the mozilla machine. > In the simplest case, you would just have a generic "labeled_ipsec_t" Type that would be specified for all the spd rules that pertain to labeled-ipsec. All the different domains that need to use labeled-ipsec would then polmatch to labeled_ipsec_t. The SAs will always and automatically be using the originating domain Type. So, the SA from the client to server would be auto-labeled mozilla_t, rss_aggregator_t, etc. (on both ends), and the SA from the server to client would be auto-labeled httpd_t (again on both ends). From jantill at redhat.com Wed Nov 29 21:14:51 2006 From: jantill at redhat.com (James Antill) Date: Wed, 29 Nov 2006 16:14:51 -0500 Subject: [redhat-lspp] Xinetd patches for selinux context configuration In-Reply-To: <1164828126.23019.239.camel@moss-spartans.epoch.ncsc.mil> References: <1164755591.18588.16.camel@code.and.org> <200611290100.25530.paul.moore@hp.com> <1164783994.18588.35.camel@code.and.org> <200611290817.15730.paul.moore@hp.com> <1164814297.23019.152.camel@moss-spartans.epoch.ncsc.mil> <1164827057.18588.44.camel@code.and.org> <1164828126.23019.239.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1164834891.18588.52.camel@code.and.org> On Wed, 2006-11-29 at 14:22 -0500, Stephen Smalley wrote: > > Ok, I assume you still also want the MLS range to be configurably bound > > as in: > > > > http://www.redhat.com/archives/redhat-lspp/2005-September/msg00125.html > > Yes, although one might be able to handle that in the labeled networking > code itself, by rejecting packets with labels outside of the client > host's authorized range before they are ever received by userspace. Ok, this patch doesn't do any bounding then. I've currently left the old config. context stuff in atm. in case we want to change that to specify the MLS bound, it's easier for me. But if this is fine as is I'll drop that part before I hand it off to Steve. > > "user_u:system_r:fingerd_exec_t", > > Not quite - this should be an object context; you should have used > object_r above. Right, this would be: system_u:object_r:fingerd_exec_t > > PROCESS__DYNTRANSITION, > > Completely wrong - this should be a security class value, not a > permission value. In particular, SECCLASS_PROCESS. Ahh, duh! Not sure what I was thinking there. Here is an updated patch, all of the real changes are localized to child.c now, I think: diff -rup xinetd-2.3.14-orig/xinetd/attr.h xinetd-2.3.14/xinetd/attr.h --- xinetd-2.3.14-orig/xinetd/attr.h 2005-10-05 13:15:33.000000000 -0400 +++ xinetd-2.3.14/xinetd/attr.h 2006-11-29 15:55:07.000000000 -0500 @@ -61,12 +61,13 @@ #define A_DISABLED 43 #define A_MDNS 44 #define A_LIBWRAP 45 +#define A_SEC_CONTEXT 46 /* * SERVICE_ATTRIBUTES is the number of service attributes and also * the number from which defaults-only attributes start. */ -#define SERVICE_ATTRIBUTES ( A_MDNS + 1 ) +#define SERVICE_ATTRIBUTES ( A_SEC_CONTEXT + 1 ) /* * Mask of attributes that must be specified. Only in xinetd-2.3.14/xinetd: attr.h.confcntx diff -rup xinetd-2.3.14-orig/xinetd/child.c xinetd-2.3.14/xinetd/child.c --- xinetd-2.3.14-orig/xinetd/child.c 2006-11-28 14:03:07.000000000 -0500 +++ xinetd-2.3.14/xinetd/child.c 2006-11-29 15:55:27.000000000 -0500 @@ -31,9 +31,6 @@ #ifdef HAVE_NETDB_H #include #endif -#ifdef LABELED_NET -#include -#endif #include "str.h" #include "child.h" @@ -49,7 +46,8 @@ /* Local declarations */ #ifdef LABELED_NET -static int set_context_from_socket( int fd ); +static int set_context_from_socket( const struct service_config *scp, int fd ); +static int set_context_from_config( const struct service_config *scp ); #endif @@ -158,12 +156,17 @@ void exec_server( const struct server *s #ifdef LABELED_NET if (SC_LABELED_NET(scp)) { - if (set_context_from_socket( descriptor ) < 0) { + if (set_context_from_socket( scp, descriptor ) < 0) { msg( LOG_ERR, func, "Changing process context failed for %s", SC_ID( scp )) ; _exit( 1 ) ; } } + else if (set_context_from_config( scp ) < 0) { + msg( LOG_ERR, func, + "Changing process context failed for %s", SC_ID( scp )) ; + _exit( 1 ) ; + } #endif (void) Sclose( descriptor ) ; @@ -485,16 +488,11 @@ void child_exit(void) } #ifdef LABELED_NET -static int set_context_from_socket( int fd ) +static int set_context( security_context_t cntx ) { - const char *func = "set_context_from_socket" ; - security_context_t peer_context; + const char *func = "set_context" ; - if (getpeercon(fd, &peer_context) < 0) - return -1; - - int retval = setexeccon(peer_context); - freecon( peer_context ); + int retval = setexeccon(cntx); if (debug.on) { @@ -513,4 +511,74 @@ static int set_context_from_socket( int return retval; } + +static int set_context_from_socket( const struct service_config *scp, int fd ) +{ + security_context_t curr_context; + security_context_t peer_context; + security_context_t exec_context; + context_t bcon; + context_t pcon; + security_context_t new_context; + security_context_t new_exec_context; + int retval = -1; + const char *exepath = NULL; + + if (getcon(&curr_context) < 0) + goto fail_getcon; + + if (getpeercon(fd, &peer_context) < 0) + goto fail_getpeercon; + + exepath = SC_SERVER_ARGV( scp )[0]; + if (lgetfilecon(exepath, &exec_context) < 0) + goto fail_lgetfilecon; + + if (!(bcon = context_new(curr_context))) + goto fail_context_new_curr; + + if (!(pcon = context_new(peer_context))) + goto fail_context_new_peer; + + if (!context_range_get(pcon)) + goto fail_context_range_get; + + if (!context_range_set(bcon, context_range_get(pcon))) + goto fail_context_range_set; + + if (!(new_context = context_str(bcon))) + goto fail_context_str; + + if (security_compute_create(new_context, exec_context, SECCLASS_PROCESS, + &new_exec_context) < 0) + goto fail_security_compute_create; + + retval = set_context(new_exec_context); + + freecon(new_exec_context); + + fail_security_compute_create: + fail_context_str: + fail_context_range_set: + fail_context_range_get: + context_free(pcon); + fail_context_new_peer: + context_free(bcon); + fail_context_new_curr: + freecon(exec_context); + fail_lgetfilecon: + freecon(peer_context); + fail_getpeercon: + freecon(curr_context); + fail_getcon: + return retval; +} + +static int set_context_from_config( const struct service_config *scp ) +{ + if (!SC_HAS_SEC_CONTEXT(scp)) /* no config. don't do anything */ + return 0; + + return set_context(SC_SEC_CONTEXT(scp)); +} #endif Only in xinetd-2.3.14/xinetd: child.c.confcntx diff -rup xinetd-2.3.14-orig/xinetd/parse.c xinetd-2.3.14/xinetd/parse.c --- xinetd-2.3.14-orig/xinetd/parse.c 2005-10-05 13:15:33.000000000 -0400 +++ xinetd-2.3.14/xinetd/parse.c 2006-11-29 15:55:07.000000000 -0500 @@ -98,6 +98,10 @@ static const struct attribute service_at #ifdef RLIMIT_STACK { "rlimit_stack", A_RLIMIT_STACK, 1, rlim_stack_parser }, #endif +#ifdef LABELED_NET + { "sec_context", A_SEC_CONTEXT, 1, selinux_context_parser }, + { "selinux_context",A_SEC_CONTEXT, 1, selinux_context_parser }, +#endif { "v6only", A_V6ONLY, 1, v6only_parser }, { "deny_time", A_DENY_TIME, 1, deny_time_parser }, { "umask", A_UMASK, 1, umask_parser }, Only in xinetd-2.3.14/xinetd: parse.c.confcntx diff -rup xinetd-2.3.14-orig/xinetd/parsers.c xinetd-2.3.14/xinetd/parsers.c --- xinetd-2.3.14-orig/xinetd/parsers.c 2005-10-05 17:45:41.000000000 -0400 +++ xinetd-2.3.14/xinetd/parsers.c 2006-11-29 15:55:07.000000000 -0500 @@ -1513,3 +1513,24 @@ status_e libwrap_parser( pset_h values, } #endif +#ifdef LABELED_NET +status_e selinux_context_parser(pset_h values, + struct service_config *scp, enum assign_op op) +{ + const char *func = "selinux_context_parser"; + + if( pset_pointer(values, 0) == NULL ) + { + msg(LOG_ERR, func, "pset_pointer returned NULL"); + return( FAILED ); + } + + SC_SEC_CONTEXT(scp) = new_string( pset_pointer(values,0) ); + if( SC_SEC_CONTEXT(scp) == NULL ) { + msg(LOG_ERR, func, ES_NOMEM); + return( FAILED ); + } + + return OK; +} +#endif Only in xinetd-2.3.14/xinetd: parsers.c.confcntx diff -rup xinetd-2.3.14-orig/xinetd/parsers.h xinetd-2.3.14/xinetd/parsers.h --- xinetd-2.3.14-orig/xinetd/parsers.h 2005-10-05 13:15:33.000000000 -0400 +++ xinetd-2.3.14/xinetd/parsers.h 2006-11-29 15:55:07.000000000 -0500 @@ -70,5 +70,9 @@ status_e mdns_parser(pset_h, struct serv #ifdef LIBWRAP status_e libwrap_parser(pset_h, struct service_config *, enum assign_op) ; #endif +#ifdef LABELED_NET +status_e selinux_context_parser(pset_h values, + struct service_config *scp, enum assign_op op) ; +#endif #endif Only in xinetd-2.3.14/xinetd: parsers.h.confcntx diff -rup xinetd-2.3.14-orig/xinetd/sconf.h xinetd-2.3.14/xinetd/sconf.h --- xinetd-2.3.14-orig/xinetd/sconf.h 2006-11-28 14:03:07.000000000 -0500 +++ xinetd-2.3.14/xinetd/sconf.h 2006-11-29 15:55:07.000000000 -0500 @@ -25,6 +25,12 @@ #endif #include "libportable.h" +#ifdef LABELED_NET +#include +#include +#include +#endif + #include "pset.h" #include "m_env.h" #include "mask.h" @@ -158,6 +164,9 @@ struct service_config #ifdef LIBWRAP char *sc_libwrap; #endif +#ifdef LABELED_NET + security_context_t sc_sec_context; +#endif } ; #define SCP( p ) ((struct service_config *)(p)) @@ -219,6 +228,7 @@ struct service_config #define SC_MDNS( scp ) (scp)->sc_mdns #define SC_PER_SOURCE( scp ) (scp)->sc_per_source #define SC_LIBWRAP( scp ) (scp)->sc_libwrap +#define SC_SEC_CONTEXT( scp ) (scp)->sc_sec_context /* * Field set macros */ @@ -255,6 +265,8 @@ struct service_config #define SC_IS_TCPMUX( scp ) ( (scp)->sc_builtin && \ (BUILTIN_HANDLER( (scp)->sc_builtin ) == \ (void *)tcpmux_handler ) ) +#define SC_HAS_SEC_CONTEXT(scp) ( (scp)->sc_sec_context && \ + *(scp)->sc_sec_context) #define LOGS_USERID( scp, flags ) \ ( M_IS_SET( (scp)->flags, LO_USERID ) && SC_ACCEPTS_CONNECTIONS( scp ) ) Only in xinetd-2.3.14/xinetd: sconf.h.confcntx -- James Antill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sds at tycho.nsa.gov Wed Nov 29 21:22:35 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 29 Nov 2006 16:22:35 -0500 Subject: [redhat-lspp] Xinetd patches for selinux context configuration In-Reply-To: <1164834891.18588.52.camel@code.and.org> References: <1164755591.18588.16.camel@code.and.org> <200611290100.25530.paul.moore@hp.com> <1164783994.18588.35.camel@code.and.org> <200611290817.15730.paul.moore@hp.com> <1164814297.23019.152.camel@moss-spartans.epoch.ncsc.mil> <1164827057.18588.44.camel@code.and.org> <1164828126.23019.239.camel@moss-spartans.epoch.ncsc.mil> <1164834891.18588.52.camel@code.and.org> Message-ID: <1164835355.23019.277.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-11-29 at 16:14 -0500, James Antill wrote: > diff -rup xinetd-2.3.14-orig/xinetd/child.c xinetd-2.3.14/xinetd/child.c > --- xinetd-2.3.14-orig/xinetd/child.c 2006-11-28 14:03:07.000000000 > -0500 > +++ xinetd-2.3.14/xinetd/child.c 2006-11-29 15:55:27.000000000 -0500 > @@ -513,4 +511,74 @@ static int set_context_from_socket( int > > return retval; > } > + > +static int set_context_from_socket( const struct service_config *scp, > int fd ) > +{ > + security_context_t curr_context; > + security_context_t peer_context; > + security_context_t exec_context; > + context_t bcon; > + context_t pcon; > + security_context_t new_context; > + security_context_t new_exec_context; If you init these variables to NULL, you can unconditionally free them on the exit path and not require as many distinct labels. > + int retval = -1; > + const char *exepath = NULL; > + > + if (getcon(&curr_context) < 0) > + goto fail_getcon; > + > + if (getpeercon(fd, &peer_context) < 0) > + goto fail_getpeercon; > + > + exepath = SC_SERVER_ARGV( scp )[0]; > + if (lgetfilecon(exepath, &exec_context) < 0) > + goto fail_lgetfilecon; You want getfilecon() here rather than lgetfilecon(), since you want the context of the executable that will be executed by execve, not any symlink to it. > + if (!context_range_get(pcon)) > + goto fail_context_range_get; > + > + if (!context_range_set(bcon, context_range_get(pcon))) > + goto fail_context_range_set; context_range_set returns nonzero upon failure - looks like the man page is wrong for the _set functions. -- Stephen Smalley National Security Agency From sgrubb at redhat.com Wed Nov 29 21:29:54 2006 From: sgrubb at redhat.com (Steve Grubb) Date: Wed, 29 Nov 2006 16:29:54 -0500 Subject: [redhat-lspp] Xinetd patches for selinux context configuration In-Reply-To: <1164834891.18588.52.camel@code.and.org> References: <1164755591.18588.16.camel@code.and.org> <1164828126.23019.239.camel@moss-spartans.epoch.ncsc.mil> <1164834891.18588.52.camel@code.and.org> Message-ID: <200611291629.54117.sgrubb@redhat.com> On Wednesday 29 November 2006 16:14, James Antill wrote: > ?Ok, this patch doesn't do any bounding then. > ?I've currently left the old config. context stuff in atm. in case we > want to change that to specify the MLS bound, it's easier for me. But if > this is fine as is I'll drop that part before I hand it off to Steve. If we are adding a parser to xinetd, it needs to check that the context it read is indeed valid. Also, xinetd does an integrated check in check_entry(), confparse.c. It needs to do some paranoid checks that they are not specifying a label when labeled networking flag is not given. -Steve From sds at tycho.nsa.gov Wed Nov 29 21:32:45 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 29 Nov 2006 16:32:45 -0500 Subject: [redhat-lspp] Xinetd patches for selinux context configuration In-Reply-To: <200611291629.54117.sgrubb@redhat.com> References: <1164755591.18588.16.camel@code.and.org> <1164828126.23019.239.camel@moss-spartans.epoch.ncsc.mil> <1164834891.18588.52.camel@code.and.org> <200611291629.54117.sgrubb@redhat.com> Message-ID: <1164835965.23019.283.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-11-29 at 16:29 -0500, Steve Grubb wrote: > On Wednesday 29 November 2006 16:14, James Antill wrote: > > Ok, this patch doesn't do any bounding then. > > I've currently left the old config. context stuff in atm. in case we > > want to change that to specify the MLS bound, it's easier for me. But if > > this is fine as is I'll drop that part before I hand it off to Steve. > > If we are adding a parser to xinetd, it needs to check that the context it > read is indeed valid. Also, xinetd does an integrated check in check_entry(), > confparse.c. It needs to do some paranoid checks that they are not specifying > a label when labeled networking flag is not given. security_check_context(3) can be used to validate a context against the active policy. I'm not sure the approach is quite workable yet either - if you configure xinetd to use labeled networking but the incoming connection is coming from a host that doesn't support it, getpeercon() will fail and you need to gracefully deal with it (e.g. fall back to some default, possibly based on the client machine's address). -- Stephen Smalley National Security Agency From jantill at redhat.com Wed Nov 29 22:08:39 2006 From: jantill at redhat.com (James Antill) Date: Wed, 29 Nov 2006 17:08:39 -0500 Subject: [redhat-lspp] Xinetd patches for selinux context configuration In-Reply-To: <1164835355.23019.277.camel@moss-spartans.epoch.ncsc.mil> References: <1164755591.18588.16.camel@code.and.org> <200611290100.25530.paul.moore@hp.com> <1164783994.18588.35.camel@code.and.org> <200611290817.15730.paul.moore@hp.com> <1164814297.23019.152.camel@moss-spartans.epoch.ncsc.mil> <1164827057.18588.44.camel@code.and.org> <1164828126.23019.239.camel@moss-spartans.epoch.ncsc.mil> <1164834891.18588.52.camel@code.and.org> <1164835355.23019.277.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1164838119.18588.56.camel@code.and.org> On Wed, 2006-11-29 at 16:22 -0500, Stephen Smalley wrote: > > + exepath = SC_SERVER_ARGV( scp )[0]; > > + if (lgetfilecon(exepath, &exec_context) < 0) > > + goto fail_lgetfilecon; > > You want getfilecon() here rather than lgetfilecon(), since you want the > context of the executable that will be executed by execve, not any > symlink to it. Right. > > + if (!context_range_get(pcon)) > > + goto fail_context_range_get; > > + > > + if (!context_range_set(bcon, context_range_get(pcon))) > > + goto fail_context_range_set; > > context_range_set returns nonzero upon failure - looks like the man page > is wrong for the _set functions. Fixed. I removed the config. stuff for this version, so this should be ready to include. diff -rup xinetd-2.3.14-orig/xinetd/child.c xinetd-2.3.14/xinetd/child.c --- xinetd-2.3.14-orig/xinetd/child.c 2006-11-28 14:03:07.000000000 -0500 +++ xinetd-2.3.14/xinetd/child.c 2006-11-29 17:04:19.000000000 -0500 @@ -33,6 +33,8 @@ #endif #ifdef LABELED_NET #include +#include +#include #endif #include "str.h" @@ -49,7 +51,7 @@ /* Local declarations */ #ifdef LABELED_NET -static int set_context_from_socket( int fd ); +static int set_context_from_socket( const struct service_config *scp, int fd ); #endif @@ -158,7 +160,7 @@ void exec_server( const struct server *s #ifdef LABELED_NET if (SC_LABELED_NET(scp)) { - if (set_context_from_socket( descriptor ) < 0) { + if (set_context_from_socket( scp, descriptor ) < 0) { msg( LOG_ERR, func, "Changing process context failed for %s", SC_ID( scp )) ; _exit( 1 ) ; @@ -485,16 +487,11 @@ void child_exit(void) } #ifdef LABELED_NET -static int set_context_from_socket( int fd ) +static int set_context( security_context_t cntx ) { - const char *func = "set_context_from_socket" ; - security_context_t peer_context; + const char *func = "set_context" ; - if (getpeercon(fd, &peer_context) < 0) - return -1; - - int retval = setexeccon(peer_context); - freecon( peer_context ); + int retval = setexeccon(cntx); if (debug.on) { @@ -513,4 +510,59 @@ static int set_context_from_socket( int return retval; } + +static int set_context_from_socket( const struct service_config *scp, int fd ) +{ + security_context_t curr_context = NULL; + security_context_t peer_context = NULL; + security_context_t exec_context = NULL; + context_t bcon = NULL; + context_t pcon = NULL; + security_context_t new_context = NULL; + security_context_t new_exec_context = NULL; + int retval = -1; + const char *exepath = NULL; + + if (getcon(&curr_context) < 0) + goto fail; + + if (getpeercon(fd, &peer_context) < 0) + goto fail; + + exepath = SC_SERVER_ARGV( scp )[0]; + if (getfilecon(exepath, &exec_context) < 0) + goto fail; + + if (!(bcon = context_new(curr_context))) + goto fail; + + if (!(pcon = context_new(peer_context))) + goto fail; + + if (!context_range_get(pcon)) + goto fail; + + if (context_range_set(bcon, context_range_get(pcon))) + goto fail; + + if (!(new_context = context_str(bcon))) + goto fail; + + if (security_compute_create(new_context, exec_context, SECCLASS_PROCESS, + &new_exec_context) < 0) + goto fail; + + retval = set_context(new_exec_context); + + freecon(new_exec_context); + + fail: + context_free(pcon); + context_free(bcon); + freecon(exec_context); + freecon(peer_context); + freecon(curr_context); + + return retval; +} #endif -- James Antill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jantill at redhat.com Wed Nov 29 22:10:14 2006 From: jantill at redhat.com (James Antill) Date: Wed, 29 Nov 2006 17:10:14 -0500 Subject: [redhat-lspp] Xinetd patches for selinux context configuration In-Reply-To: <1164835965.23019.283.camel@moss-spartans.epoch.ncsc.mil> References: <1164755591.18588.16.camel@code.and.org> <1164828126.23019.239.camel@moss-spartans.epoch.ncsc.mil> <1164834891.18588.52.camel@code.and.org> <200611291629.54117.sgrubb@redhat.com> <1164835965.23019.283.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1164838214.18588.58.camel@code.and.org> On Wed, 2006-11-29 at 16:32 -0500, Stephen Smalley wrote: > I'm not sure the approach is quite workable yet either - if you > configure xinetd to use labeled networking but the incoming connection > is coming from a host that doesn't support it, getpeercon() will fail > and you need to gracefully deal with it (e.g. fall back to some default, > possibly based on the client machine's address). Isn't this exactly what netlabel is for? Do we really want to duplicate that for each daemon? -- James Antill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From paul.moore at hp.com Wed Nov 29 22:13:54 2006 From: paul.moore at hp.com (Paul Moore) Date: Wed, 29 Nov 2006 17:13:54 -0500 Subject: [redhat-lspp] Xinetd patches for selinux context configuration In-Reply-To: <1164838214.18588.58.camel@code.and.org> References: <1164755591.18588.16.camel@code.and.org> <1164828126.23019.239.camel@moss-spartans.epoch.ncsc.mil> <1164834891.18588.52.camel@code.and.org> <200611291629.54117.sgrubb@redhat.com> <1164835965.23019.283.camel@moss-spartans.epoch.ncsc.mil> <1164838214.18588.58.camel@code.and.org> Message-ID: <456E0622.8030403@hp.com> James Antill wrote: > On Wed, 2006-11-29 at 16:32 -0500, Stephen Smalley wrote: > >>I'm not sure the approach is quite workable yet either - if you >>configure xinetd to use labeled networking but the incoming connection >>is coming from a host that doesn't support it, getpeercon() will fail >>and you need to gracefully deal with it (e.g. fall back to some default, >>possibly based on the client machine's address). > > Isn't this exactly what netlabel is for? Do we really want to duplicate > that for each daemon? NetLabel is a method of explicit labeled networking, i.e. it sends security attributes with each packet that both hosts must understand. -- paul moore linux security @ hp From jantill at redhat.com Wed Nov 29 23:30:22 2006 From: jantill at redhat.com (James Antill) Date: Wed, 29 Nov 2006 18:30:22 -0500 Subject: [redhat-lspp] Xinetd patches for selinux context configuration In-Reply-To: <456E0622.8030403@hp.com> References: <1164755591.18588.16.camel@code.and.org> <1164828126.23019.239.camel@moss-spartans.epoch.ncsc.mil> <1164834891.18588.52.camel@code.and.org> <200611291629.54117.sgrubb@redhat.com> <1164835965.23019.283.camel@moss-spartans.epoch.ncsc.mil> <1164838214.18588.58.camel@code.and.org> <456E0622.8030403@hp.com> Message-ID: <1164843022.18588.61.camel@code.and.org> On Wed, 2006-11-29 at 17:13 -0500, Paul Moore wrote: > James Antill wrote: > > On Wed, 2006-11-29 at 16:32 -0500, Stephen Smalley wrote: > > > >>I'm not sure the approach is quite workable yet either - if you > >>configure xinetd to use labeled networking but the incoming connection > >>is coming from a host that doesn't support it, getpeercon() will fail > >>and you need to gracefully deal with it (e.g. fall back to some default, > >>possibly based on the client machine's address). > > > > Isn't this exactly what netlabel is for? Do we really want to duplicate > > that for each daemon? > > NetLabel is a method of explicit labeled networking, i.e. it sends security > attributes with each packet that both hosts must understand. As I understand it, you can say label received packets from host X with context Y. Is that not so? -- James Antill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From latten at austin.ibm.com Wed Nov 29 23:51:56 2006 From: latten at austin.ibm.com (Joy Latten) Date: Wed, 29 Nov 2006 17:51:56 -0600 Subject: [redhat-lspp] Re: labeled ipsec policy In-Reply-To: <001701c713f6$e02b11b0$cc0a010a@tcssec.com> References: <001701c713f6$e02b11b0$cc0a010a@tcssec.com> Message-ID: <1164844316.17737.513.camel@faith.austin.ibm.com> On Wed, 2006-11-29 at 14:42 -0600, Venkat Yekkirala wrote: > > I'm not very sure how users will use the SPD labeling. I suspect that > > they will be labeled with probably the other side's domain type. For > > example, if httpd_t and mozilla_t are connected, the SPD would be > > mozilla_t on the http machine and httpd_t on the mozilla machine. > > > > In the simplest case, you would just have a generic "labeled_ipsec_t" Type > that would be specified for all the spd rules that pertain to labeled-ipsec. > All the different domains that need to use labeled-ipsec would then polmatch > to labeled_ipsec_t. > > The SAs will always and automatically be using the originating domain Type. > So, the SA from the client to server would be auto-labeled mozilla_t, > rss_aggregator_t, etc. (on both ends), and the SA from the server to client > would be auto-labeled httpd_t (again on both ends). Ok, so then I will go with my original idea of a type ipsec_spd_t and create an interface that allows sysadmins to create selinux policy for "polmatching" ipsec SAs to the ipsec policy type, ipsec_spd_t. Thanks!! Joy From paul.moore at hp.com Thu Nov 30 02:11:11 2006 From: paul.moore at hp.com (Paul Moore) Date: Wed, 29 Nov 2006 21:11:11 -0500 Subject: [redhat-lspp] Xinetd patches for selinux context configuration In-Reply-To: <1164843022.18588.61.camel@code.and.org> References: <1164755591.18588.16.camel@code.and.org> <456E0622.8030403@hp.com> <1164843022.18588.61.camel@code.and.org> Message-ID: <200611292111.12192.paul.moore@hp.com> On Wednesday 29 November 2006 6:30 pm, James Antill wrote: > On Wed, 2006-11-29 at 17:13 -0500, Paul Moore wrote: > > James Antill wrote: > > > On Wed, 2006-11-29 at 16:32 -0500, Stephen Smalley wrote: > > >>I'm not sure the approach is quite workable yet either - if you > > >>configure xinetd to use labeled networking but the incoming connection > > >>is coming from a host that doesn't support it, getpeercon() will fail > > >>and you need to gracefully deal with it (e.g. fall back to some > > >> default, possibly based on the client machine's address). > > > > > > Isn't this exactly what netlabel is for? Do we really want to > > > duplicate that for each daemon? > > > > NetLabel is a method of explicit labeled networking, i.e. it sends > > security attributes with each packet that both hosts must understand. > > As I understand it, you can say label received packets from host X with > context Y. Is that not so? Sorry for any confusion, I thought you were implying that NetLabel assigns a context to a packet simply based on the IP address of the remote host. A better explanation of NetLabel/CIPSO is below ... For NetLabel if the incoming packet is labeled by the remote host, i.e. a CIPSO IP option is present in the packet's headers, then NetLabel will create a context for the packet based on the concatenation of the SECINITSID_UNLABELED TE values and the CIPSO option's MLS label. In practice this allows you to say that domain X is allowed to receive packets from remote domains/processes which are running with the same MLS label; if domain X has the right MLS type attributes associated with it then it can receive packets from remote domains/processes that do not match it's own MLS label (see the MLS constraints file to see what I mean). The IP address of the remote host never comes into play. -- paul moore linux security @ hp From sds at tycho.nsa.gov Thu Nov 30 13:06:26 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 30 Nov 2006 08:06:26 -0500 Subject: [redhat-lspp] Xinetd patches for selinux context configuration In-Reply-To: <1164843022.18588.61.camel@code.and.org> References: <1164755591.18588.16.camel@code.and.org> <1164828126.23019.239.camel@moss-spartans.epoch.ncsc.mil> <1164834891.18588.52.camel@code.and.org> <200611291629.54117.sgrubb@redhat.com> <1164835965.23019.283.camel@moss-spartans.epoch.ncsc.mil> <1164838214.18588.58.camel@code.and.org> <456E0622.8030403@hp.com> <1164843022.18588.61.camel@code.and.org> Message-ID: <1164891986.23019.296.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-11-29 at 18:30 -0500, James Antill wrote: > On Wed, 2006-11-29 at 17:13 -0500, Paul Moore wrote: > > James Antill wrote: > > > On Wed, 2006-11-29 at 16:32 -0500, Stephen Smalley wrote: > > > > > >>I'm not sure the approach is quite workable yet either - if you > > >>configure xinetd to use labeled networking but the incoming connection > > >>is coming from a host that doesn't support it, getpeercon() will fail > > >>and you need to gracefully deal with it (e.g. fall back to some default, > > >>possibly based on the client machine's address). > > > > > > Isn't this exactly what netlabel is for? Do we really want to duplicate > > > that for each daemon? > > > > NetLabel is a method of explicit labeled networking, i.e. it sends security > > attributes with each packet that both hosts must understand. > > As I understand it, you can say label received packets from host X with > context Y. Is that not so? I think you are confusing netlabel with secmark, and also still thinking about secid reconciliation (which didn't get accepted). If secid reconciliation had been accepted, then yes, you could assign a default label based on client host or other properties of the packet via secmark and have it returned by getpeercon if there was no explicit label on the packet. But the final resolution of that lengthy debate was that secmark would remain separate from labeled networking, and that getpeercon would only return a context if labeled networking was in use on the connection (likewise for SCM_SECURITY on datagrams). I agree though that replicating the lookup of a default context by host per daemon wouldn't be desirable, so one might want a general service provided by libselinux. A topic for selinux list, not here, yet again. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Thu Nov 30 14:54:08 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 30 Nov 2006 09:54:08 -0500 Subject: [redhat-lspp] Xinetd patches for selinux context configuration In-Reply-To: <1164891986.23019.296.camel@moss-spartans.epoch.ncsc.mil> References: <1164755591.18588.16.camel@code.and.org> <1164828126.23019.239.camel@moss-spartans.epoch.ncsc.mil> <1164834891.18588.52.camel@code.and.org> <200611291629.54117.sgrubb@redhat.com> <1164835965.23019.283.camel@moss-spartans.epoch.ncsc.mil> <1164838214.18588.58.camel@code.and.org> <456E0622.8030403@hp.com> <1164843022.18588.61.camel@code.and.org> <1164891986.23019.296.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1164898448.23019.329.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2006-11-30 at 08:06 -0500, Stephen Smalley wrote: > On Wed, 2006-11-29 at 18:30 -0500, James Antill wrote: > > On Wed, 2006-11-29 at 17:13 -0500, Paul Moore wrote: > > > James Antill wrote: > > > > On Wed, 2006-11-29 at 16:32 -0500, Stephen Smalley wrote: > > > > > > > >>I'm not sure the approach is quite workable yet either - if you > > > >>configure xinetd to use labeled networking but the incoming connection > > > >>is coming from a host that doesn't support it, getpeercon() will fail > > > >>and you need to gracefully deal with it (e.g. fall back to some default, > > > >>possibly based on the client machine's address). > > > > > > > > Isn't this exactly what netlabel is for? Do we really want to duplicate > > > > that for each daemon? > > > > > > NetLabel is a method of explicit labeled networking, i.e. it sends security > > > attributes with each packet that both hosts must understand. > > > > As I understand it, you can say label received packets from host X with > > context Y. Is that not so? > > I think you are confusing netlabel with secmark, and also still thinking > about secid reconciliation (which didn't get accepted). If secid > reconciliation had been accepted, then yes, you could assign a default > label based on client host or other properties of the packet via secmark > and have it returned by getpeercon if there was no explicit label on the > packet. But the final resolution of that lengthy debate was that > secmark would remain separate from labeled networking, and that > getpeercon would only return a context if labeled networking was in use > on the connection (likewise for SCM_SECURITY on datagrams). > > I agree though that replicating the lookup of a default context by host > per daemon wouldn't be desirable, so one might want a general service > provided by libselinux. A topic for selinux list, not here, yet again. BTW, libsepol and libsemanage already have a notion of node (host) contexts, although those are defined in the policy for certain permission checks (node_bind, compat send/recv per-packet checks). Not sure whether you can leverage the range portion of those contexts for this purpose. -- Stephen Smalley National Security Agency From vyekkirala at trustedcs.com Thu Nov 30 15:57:08 2006 From: vyekkirala at trustedcs.com (Venkat Yekkirala) Date: Thu, 30 Nov 2006 09:57:08 -0600 Subject: [redhat-lspp] Re: labeled ipsec policy In-Reply-To: <1164844316.17737.513.camel@faith.austin.ibm.com> Message-ID: <001801c71498$3173b6c0$cc0a010a@tcssec.com> > > > I'm not very sure how users will use the SPD labeling. I > suspect that > > > they will be labeled with probably the other side's > domain type. For > > > example, if httpd_t and mozilla_t are connected, the SPD would be > > > mozilla_t on the http machine and httpd_t on the mozilla machine. > > > > > > > In the simplest case, you would just have a generic > "labeled_ipsec_t" Type > > that would be specified for all the spd rules that pertain > to labeled-ipsec. > > All the different domains that need to use labeled-ipsec > would then polmatch > > to labeled_ipsec_t. > > > > The SAs will always and automatically be using the s/always/always (when the spd rule has a context associate with it)/ > originating domain Type. > > So, the SA from the client to server would be auto-labeled > mozilla_t, > > rss_aggregator_t, etc. (on both ends), and the SA from the > server to client > > would be auto-labeled httpd_t (again on both ends). > > Ok, so then I will go with my original idea of a type ipsec_spd_t and > create an interface that allows sysadmins to create selinux policy for > "polmatching" ipsec SAs to the ipsec policy type, > ipsec_spd_t. Thanks!! > > Joy >