From latten at austin.ibm.com Thu Feb 1 01:33:22 2007 From: latten at austin.ibm.com (Joy Latten) Date: Wed, 31 Jan 2007 19:33:22 -0600 Subject: [redhat-lspp] Labeled IPsec localhost problems In-Reply-To: <200701311732.57378.paul.moore@hp.com> References: <200701301743.15048.paul.moore@hp.com> <200701302314.39453.paul.moore@hp.com> <1170279221.2603.249.camel@faith.austin.ibm.com> <200701311732.57378.paul.moore@hp.com> Message-ID: <1170293602.2603.308.camel@faith.austin.ibm.com> On Wed, 2007-01-31 at 17:32 -0500, Paul Moore wrote: > On Wednesday, January 31 2007 4:33 pm, Joy Latten wrote: > > On Tue, 2007-01-30 at 23:14 -0500, Paul Moore wrote: > > > > By the way, I ran one last night with labeled ipsec over ipv6 with > > > > your patch and happy to report the stress test completed a 15 hour > > > > run successfully. So at least no regression on that front. > > > > > > Great, thank you for testing this. Out of curiosity, how many times > > > during the test did the phase-2 SAs get re-keyed, i.e. what was the SA > > > lifetime? > > > > ISAKMP SA lifetime is 30 minutes and IPSEC SA is 15 minutes. And test > > ran for 15 hours sending streams of udp and tcp packets. I also had > > both esp and ah configured to be used. > > Good to know thanks. I wanted to make sure we were hitting the IKE > negotiation code and it looks like we hit it quite a few times. > > > > That is exactly the problem I am concerned about too ... using the > > > standard IPsec selectors of src,dst,proto,port I'm not sure there is a > > > way to differentiate connections between two localhost addresses in all > > > cases; for example, what happens if you want to label ICMP traffic across > > > localhost? > > > > Ok, I am going to talk myself through this, I apologize ahead of time > > if it is too much info and I will skip over stuff since xfrm process is > > kind of a lot to me. :-) > > It's a lot for anybody to wrap their head around :) > > > This is not exclusive to loopback. What if I have a traffic stream > > 10.1.1.1->10.1.2.3 and I have specified a separate ipsec policy for each > > upper layer protocol, udp, tcp, and icmp. This gives me 3 pairs of > > policy entries (6 entries altogether) with exact same info except for > > the upper-layer protocol. Well, in regular ipsec, this will result in a > > single pair of SAs, that will be used for icmp, udp, and tcp traffic. > > This single pair of SAs will be associated with all 3 pairs of policy. > > Actually, if you configure the SPD such that you have a separate policy for > UDP, TCP, and ICMP between two hosts then you will get three SA pairs, one > pair for each protocol. The protocol type is part of the IPsec selector (see > RFC 2401). > Yes, that is correct, IF there is a protocol type specified. rfc2367 states that if the ports are non-zero, then the sadb_address_proto, normally zero, MUST be filled in with transport protocol's number. So, unless you have specified ports, this field will be zero. I did try this earlier and got the results I told you about earlier. Try the following policy for an example. spdadd 10.1.1.1 10.1.2.3 tcp -P in ipsec esp/transport//require; #ah/transport//require; spdadd 10.1.2.3 10.1.1.1 tcp -P out ipsec esp/transport//require; #ah/transport//require; (create 2 more pairs and use "icmp" and "udp" instead of "tcp") > > Now with labeled ipsec, the only difference is the security context. > > The security context is the "selector" that differentiates xfrms. > > So, instead of a single pair of xfrms, we could possibly have many. > > And the code takes care of this. To find correct xfrm, we do a > > xfrm_selector_match() and if successful, then do a > > security_xfrm_state_pol_flow_match(), which checks to see if (flow->sid > > == xfrm->id) then avc_has_perm(check for association:sendto) permission. > > This ensures we get correct xfrm for the flow. Otherwise return error > > and continue to step thru xfrm list until you find another one whose > > selector matches and try again. If there is none and we have a policy, > > then call racoon. > > This gets to my original question about if the SELinux context was fully > integrated into the IPsec selectors, it looks like it has - that is good. > Have you verified this behavior over loopback? One of us should ... > I have to a small degree. I run all the stress tests in enforcing mode. I did a ping and ssh before starting tests, so there were about 6 other SAs in database before starting stress tests which creates I think 2 or 4 more. Of course a more populated database, would provide a better test... Also, I think tests would not start if correct SA was never found... > > Now with loopback the concern is we will have two exact SAs per > > security context. I am thinking that if they are exact, what does > > it matter which one gets used. We just want to make sure we use SA > > that has the correct security context and this will get done > > via security_xfrm_state_pol_flow_match() per what I said in above > > paragraph. > > If two SAs have the exact same selectors, including SELinux context, then it > probably shouldn't matter which one gets used. I'm still slightly concerned > about the AH/ESP sequence number but it's been so long since I have played > with IPsec issues like this that I only have vague reasons why this would be > a concern. > > > Venkat or anyone, please correct me if I am off on this > > or missing something. Regardless of which SA of the pair > > gets used, the SPI will ensure we pull up corresponding SA for inbound. > > I believe you are correct, the SPI should solve the bulk of the problems for > the inbound case. However, like I said earlier, it's the outbound case that > I am more concerned with as it is relies more heavily on the IPsec selectors > to ensure the correct SA is used. > > That said, it would be nice if Venkat could weigh in on this issue. > > > Now because of the policy->bundle feature, I think one of the SAs > > of the pair will always end up being used for outbound and the other > > for inbound processing. Again, unless I am missing something, I > > think it won't matter which of the 2 gets associated with inbound or > > outbound policy->bundle since they are exact. > > Well, I think the typical case is for each SA in a bundle would have a > different context. Using the client->server model I would expect one SA to > have a "client_t" context while the other would have a "server_t" context. > > > Switching back to regular labeled ipsec, I have noticed in a > > client->server model, "ssh" for example, 4 pairs of > > SAs get created per security context. A pair for server and a pair for > > client. I have noticed, when sending, the client security context is > > used. Upon receiving, the server needs to have recvfrom permission to > > use client SA. Correct SA will always get pulled up because of spi. > > > > Switching to loopback, this should work ok too. (i tried it and it did) > > Okay, good. Sorry to belabor the point, but did you verify the SPI from > packets sent by the server? For example, were the server's ACKs using a > different SPI than the client's packet? No problem, I too share your concern that we catch any holes. Ok, I tried it again to answer your question. Unfortunately, using tcpdump I could not readily distinguish the server's packet from the client's, however, during the whole session I saw only two SPIs. I mapped one spi to the client/sysadm_ssh_t's SA and the other to the server/sshd_t SA. This appeared correct to me. I am thinking that this set will always get used, and because loopback is not really bidirectional, the other set may never get used. (4 SAs get created per previously stated observations.) In case anyone wants to try, I use following ipsec policy and with latest selinux policy from Dan Walsh. You must also patch racoon with Paul's patch. spdadd 127.0.0.1 127.0.0.1 any -ctx 1 1 "system_u:object_r:ipsec_spd_t:s0-s15:c0.c1023" -P out ipsec ah/transport//require; spdadd 127.0.0.1 127.0.0.1 any -ctx 1 1 "system_u:object_r:ipsec_spd_t:s0-s15:c0.c1023" -P in ipsec ah/transport//require; I used ah so I could see more info in the tcpdump. :-) > > As for sequence numbers, their use is optional and we can > > specify/document that when using loopback, we recommend you do not use > > them since loopback has guaranteed delivery. Because yes, packets can > > get dropped when using sequence numbers and window size. > > Good to know. > > > And last but not least, I started a labeled ipsec over loopback stress > > test last night. So far it has been running for 15 hours. > > isakmp lifetime is 30 minutes > > ipsec sa lifetime is 15 minutes > > esp used over tcp and udp. > > > > I have noticed only one thing that I am concerned about. > > I have not yet figured out what it means. Although pfkey ADD fails, I > > believe the new SA has been entered because when I dump the databases, I > > notice the new spis in the SAs.The old ones are gone... > > > > My log file has the following. I think it occurs for each rekeying. > > > > Jan 31 15:12:46 tim-hv4 racoon: INFO: IPsec-SA expired: ESP/Transport > > 127.0.0.1[0]->127.0.0.1[0] spi=29906937(0x1c857f9) > > Jan 31 15:12:47 tim-hv4 racoon: INFO: IPsec-SA expired: ESP/Transport > > 127.0.0.1[0]->127.0.0.1[0] spi=200715915(0xbf6ae8b) > > Jan 31 15:12:47 tim-hv4 racoon: INFO: initiate new phase 2 negotiation: > > 127.0.0.1[0]<=>127.0.0.1[0] > > Jan 31 15:12:47 tim-hv4 racoon: INFO: respond new phase 2 negotiation: > > 127.0.0.1[0]<=>127.0.0.1[0] > > Jan 31 15:12:49 tim-hv4 racoon: INFO: IPsec-SA established: > > ESP/Transport 127.0.0.1[0]->127.0.0.1[0] spi=211935989(0xca1e2f5) > > Jan 31 15:12:49 tim-hv4 racoon: ERROR: pfkey ADD failed: File exists > > Jan 31 15:12:49 tim-hv4 racoon: INFO: IPsec-SA established: > > ESP/Transport 127.0.0.1[0]->127.0.0.1[0] spi=251963520(0xf04a880) > > Jan 31 15:12:49 tim-hv4 racoon: ERROR: pfkey ADD failed: File exists > > I saw that too, like I said, the patch was simply a proof-of-concept showing > what needed to be done to allow racoon to negotiate with itself; there is > still work that needs to be done before it is ready for actual use. > I think we should figure out why this is happening. And then you should send it to the ipsec-tools list. They are far more expert than I and may be aware of things I am not. By the way the loopback stress completed a 16.5 hour run. Only problem I saw was that message. Joy From latten at austin.ibm.com Thu Feb 1 02:01:34 2007 From: latten at austin.ibm.com (Joy Latten) Date: Wed, 31 Jan 2007 20:01:34 -0600 Subject: [redhat-lspp] Labeled IPsec localhost problems In-Reply-To: <200701311820.48187.paul.moore@hp.com> References: <200701301743.15048.paul.moore@hp.com> <1170279221.2603.249.camel@faith.austin.ibm.com> <1170284405.6447.17.camel@localhost.localdomain> <200701311820.48187.paul.moore@hp.com> Message-ID: <1170295295.2603.326.camel@faith.austin.ibm.com> On Wed, 2007-01-31 at 18:20 -0500, Paul Moore wrote: > On Wednesday, January 31 2007 6:00 pm, Eric Paris wrote: > > On Wed, 2007-01-31 at 15:33 -0600, Joy Latten wrote: > > > As for sequence numbers, their use is optional and we can > > > specify/document that when using loopback, we recommend you do not use > > > them since loopback has guaranteed delivery. Because yes, packets can > > > get dropped when using sequence numbers and window size. > > > > I'm no ipsec expert, but my understanding was that the purpose of the > > sequence number in ipsec was to prevent playback in the future. It's > > not a delivery guarantee mechanism like the seq number in TCP. Not sure > > if we care about loosing replay protection on loopback, but if it is the > > only way.... > > >From what I can recall, yes, the AH/ESP sequence number is purely for replay > protection (I'm really trying not to have to crack open the IPsec RFCs ), > which I'm not sure is all that important for loopback - after all, we kinda > have to trust out own network stack. > > My main concern with the sequence number is what would happen if you had a lot > of processes sending data and receiving data over the same SA on a large > multi-processor box - could you potentially run into a problem where you > start dropping packets because they are outside of a sequence number window? > I'm not sure because I haven't been that involved with the IPsec work that > has been going on; I was hoping that some of the people who have been working > on IPsec would know the answer ... > I don't know much about the anti-replay. Especially, whether or not loopback should have it. Perhaps someone else can answer, or even netdev or ipsec-tools lists. I looked at the code and for each xfrm, there are 2 sequence numbers. One used for outbound processing, which is incremented and value placed in SA. And one used for inbound processing, that is, it's value is used to determine if arriving SA's seq no is within window. Because an SA pair represent a traffic stream, I am guessing that in a non-loopback scenario, one of the SAs will always have outbound-seq non-zero and inbound-seq zero, and opposite for other SA in pair. This is just a guess. I have no proof, but this may be the same case for loopback. Don't really know... Joy From paul.moore at hp.com Thu Feb 1 04:50:51 2007 From: paul.moore at hp.com (Paul Moore) Date: Wed, 31 Jan 2007 23:50:51 -0500 Subject: [redhat-lspp] Labeled IPsec localhost problems In-Reply-To: <1170293602.2603.308.camel@faith.austin.ibm.com> References: <200701301743.15048.paul.moore@hp.com> <200701311732.57378.paul.moore@hp.com> <1170293602.2603.308.camel@faith.austin.ibm.com> Message-ID: <200701312350.51450.paul.moore@hp.com> On Wednesday 31 January 2007 8:33 pm, Joy Latten wrote: > On Wed, 2007-01-31 at 17:32 -0500, Paul Moore wrote: > > I saw that too, like I said, the patch was simply a proof-of-concept > > showing what needed to be done to allow racoon to negotiate with itself; > > there is still work that needs to be done before it is ready for actual > > use. > > I think we should figure out why this is happening. And then you should > send it to the ipsec-tools list. They are far more expert than I and may > be aware of things I am not. Unfortunately due to an upcoming vacation (I'm aiming for a *real* vacation, i.e. no toting a laptop around) and other evaluation related tasks I don't think I am going to be able to "drive" this fix in any sort of reasonable time frame. I spent a day looking at the racoon code and writing this patch because it looked like forward progress on this bug had stalled and I thought I might be able to jump-start a solution. I was just trying to be helpful and lend a hand ... a fresh set of eyes, yadda yadda ... You and/or Catherine (you will have to forgive me, I can't remember which one of you worked on finishing up where Venkat left off with his racoon patches) have the experience working with the ipsec-tools list and getting patches accepted upstream; I think the quickest way forward at this point is if you addressed these cleanup issues and pushed the patch forward. If you have any problems I'll do my best to help, but I just don't have the resources right now to handle this issue in a reasonable period of time. -- paul moore linux security @ hp From txtoth at gmail.com Thu Feb 1 17:25:28 2007 From: txtoth at gmail.com (Ted X Toth) Date: Thu, 01 Feb 2007 11:25:28 -0600 Subject: [redhat-lspp] LSPP Development Telecon 01/29/2007 Minutes In-Reply-To: <45C0C013.5040206@us.ibm.com> References: <45C0C013.5040206@us.ibm.com> Message-ID: <45C22288.50703@gmail.com> I think there was a discussion about naming of polyinstantiated directories that didn't make it into the notes. I don't remember all of the details of that discussion but I have submitted a pam_namespace patch and I'm just curious as to whether some version of it is going to make it into RHEL5? Ted Loulwa Salem wrote: > I think I confused voices in these notes, so feel free to correct me > if I attributed something to you that you didn't say. > > 01/29/2007 lspp Meeting Minutes: > =============================== > Attendees > > George Wilson (IBM) - GW > Lawrence Wilson (IBM) - LW > Kris Wilson (IBM) - KEW > Loulwa Salem (IBM) - LS > Michael Thompson (IBM) - MT > Joy Latten (IBM) - JL > Kylene J Hall (IBM) - KH > Irina Boverman (Red Hat) - IB > Steve Grubb (Red Hat) - SG > Dan Walsh (Red Hat) - DW > James Antill (Red Hat) - JA > Lisa Smith (HP) - LMS > Linda Knippers (HP) - LK > Matt Anderson (HP) - MA > Paul Moore (HP) - PM > Klaus Weidner (Atsec) - KW > Chad Hanson (TCS) - CH > Joe Nall - JN > Ted Toth - TT > > Tentative Agenda: > > Kernel / Beta / rawhide update > =============================== > GW: Thank you Paul for the loopback fix patch > PM: Was joy gonna do stress testing on that. I want to stress it > is a proof > of concept patch so probably there is stuff missing. I posted that to > spur some discussion. It won't surprise me if it breaks once you test > with it > JL: I am hoping for good results > PM: I noticed other issues other than racoon. The SA in phase two, > there is > no directionality since src and dst address are the same, it is > unusual > so I don't know the ramifications of that. > JL: I looked at your code and it is the same places I was looking > at. when I > was playing with manual stuff, I only needed one SA and it didn't > need > direction. I had 1 SA and it worked both ways. so i think it's > going to > be ok > PM: only thing that concerns me is sequence number and window. it is > loopback so you are guaranteed delivery > JL: I'll look at seq number. To be honest, I'm thinking who cares > about seq > number on loopback. but I'll look. I think seq number was to make > sure > we are not forging packets > PM: if there are lots of senders and receivers, what happens in > that window > will we have packet loss > JL: I'll look at that. To be honest I'm not sure we need to be > concerned. I > think seq number is optional sometimes that's why I'm saying it might > not matter. So let's just make sure > PM: Ok thank you > GW: that's extremely good for everybody .thanks Paul. How is > current kernel > looking > LS: it's good I'm using it. I have not seen any problems so far > GW: how is networking > JL: yes, it's looking good for me too > GW: with current policy and 18 kickstart, if I applied updated > packages > during post install phase system rebooted instead of panic-ing, so > it's > good. Now I don't get console login prompt. I'll look at that more. I > don't see AVC either. anyone else not seen console prompt? > LK: I've seen that problem on ia64 on first boot. just on the console > PM: I think I've seen it as well > DW: is there a getty for that > GW: there is a getty on console as far as I can tell. I'll look > into it > more. > DW: 2 things to check, check the getty and check the device is > labeled > correctly. > GW: good point since it is a hvc0 > DW: it might be problem ... > GW: I'll look into that since this is a virtual console > LK: if you reboot system, it'll be fine .. that's why it's weird. > I went to > single user mode and it came back > DW: the console came back > LK: yes, also even though you don't get prompt, I can still log in > to the > system > JA: when this happens is it running first boot graphical? > GW: I don't think so. is it even running on first boot? > JA: depends on your kickstart > MA: if it is a java console ... > KW: I've run it on VM ware and I don't see that, so I don't think > it is > related to that. > LK: I'll try to reproduce > GW: I tried to look at AVC . on first boot you can't log in as admin > anywhere. so it becomes alot more of pain. but we are making > progress we > can reboot without panic-ing. Any other issues? > > SELinux base and MLS policy update > ================================== > GW: Any policy issues > DW: we have to find out why some of you are not able to ssh as > some roles > KW: seems to be related to translation, if I comment that out it > works. > what's happening is that it has separate categories for A and B > and it > combines them. it doesn't like that sometimes > DW: you added that to bugzilla? cause I'll look at it > KW: I didn't see the bugzilla, I added that to the mailing list > MA: there were other categories that worked .. weren't those > merged together > KW: it wasn't doing that with some others > DW: if I have two categories defined it translates the entire string > KW: I think it would make sense to give translation to each label. > if it is > supposed to do that then it should work > DW: you still need to do it for each sensitivity, which is more > than desired > KW: people at lower level don't need to see higher levels. It gets > translated, but other libraries don't agree on syntax > LK: can someone log in with raw context? should they be able to > KW: translation should be at user interface level. I am slightly > surprised, > it is using sometimes the translated and sometimes the raw context > DW: I'll look into it now that I have more info > KW: mostly it is related to specific ones. > DW: library might be broken > KW: might be too late to change that. I feel more comfortable if > tools use > the translated level all the time > DW: everything should be translated to raw > KW: be careful when you are testing that because successful and > unsuccessful > ssh attempt look ok > GW: so you are advocating not being able to use translation on login > KW: should be a convenience but not affect security > MT: what's the fallout > KW: ... > DW: maybe ssh is broken, I'll figure out what's going on > MT: just for my info. going forward there was talk about defining > categories, individual components but not entire context. Is that > still > the case? > CH: that would be wonderful. > MT: the permutations get big, so I see that as being useful > DW: is A,B the same as B,A > MT: should be sanitized. categories are independent listing > CH: raw context has to be same > PM: question are the compartments related to each other if c1 c2 > c7 are > set, by convention they will display to user in order > DW: access decision is fine > KW: currently it allows us to give range of categories. if someone > comes > along and renumbers things, a tool might include things that you > might > not have expected. admin shouldn't use category ranges > DW: I don't think you can use ranges. only reason I say this is > that the > whole system would break. there is way to translate and it can > definitely use smarter engine > MA: and what about changing your translated file > KW: polyinstantiation uses translated labels. it is something > people need to > be aware of that their home dirs may go away. > MT: it should be changed to use raw > PM: there was same discussion for s-tar. stephen smalley came out > and said > he likes translated context than raw since it makes more sense > CH: it might make sense especially if you have different numbering > schema > JN: polyinstantiated dirs used to translate names .. > JA: do we have any translation which have / in them > JN: in the us government on labels it has / all over the place > LK: is there a need to have context as part of directory name > MA: this came up in last SELinux symposium. > JA: that should give you usability plus it is guaranteed unique > GW: hashed would be safest > PM: I understand this is convenient but how often is it done > KW: there is no reason why security user logged in as secret can't > read his > unclassified dir. > LK: if you check file level will you get full context > KW: kickstart uses level and category to set up polyinstantiation > not full > context. it doesn't need to be fully unique. it's a nice thing it > doesn't polyinstantiate based on user name. > JA: .. > KW: my gut feeling is keep it way it is with translated format. > raw format > has problems > JW: right we don't want to move everything to raw > KW: especially for tools ... it would be better if they use ... > CH: if old setrans file tried to concatenate A and B together... > KW: there are 2 different definitions > CH: translation library says there is no match, so I'll take A and > B and put > comma between them. > KW: if it uses syntax with commas I expect that to pass > CH: I would expect that to fail if it can't translate > KW: seems it can't translate back > GW: Other issues? > JL: kylie , lou and I saw we can't so ssh as secadm .. is there a > boolean > for that? > DW: there is a boolean. you can't specify to secadm? > KH: I'll check on that > KW: isn't secadm deprecated in this policy? > DW: might be a policy issue > GW: should we expect them to be deprecated > KW: it is not possible for sysadm to start setrans daemon in > enforcing. > DW: did you run through init? > KW: yes. I'll send an email > PM: maybe because it runs as systemHigh > KH: auditadm works ok, but not secadm.. wait I wasn't in enforcing > JL: sysadm only works, secadm and auditadm doesn't > DW: ok, it should be an easy fix. > JN: has joy changes made it to latest policy? > DW: I put them in latest > JL: I sent patch so setkey can look at directories. I sent you > patch so > setkey can't look in user home dirs for config files and such. > DW: where is user likely to create these things? > JL: I don't know where. I figured setkey should only run as > sysadm, so I > don't need to be looking in user directories. SO I changed it to > look in > sysadm user dir, /etc/ and maybe /tmp > DW: Ok, I saw the patch. I'll take another look at it > KW: problem with setrans, if you use runinit it doesn't seem to > know there > are others running, so it creates another one. It seems to have a pid > file. > DW: if you say run-init status what does it show you? > KW: shows stopped > DW: so it is not seeing pid file. what is label on pid file > KW: systemhigh > PM: what happens if you try to query if you are at systemhigh > KW: I get no such file or directory for pid file. > > PAM and VFS polyinstantiation > ============================== > > ssh level selection > ==================== > > IPsec localhost, IPv6, 1st packet drop > ====================================== > GW: talked about most of networking. first packet drop is not > going to get > fixed anytime soon since it is a big fix. I am wondering the > ramifications > JN: I think it is a big impact > JN: there was email with james morris and he said he had a patch > but it > wasn't ready for prime time. he said I should use openswan. I was > surprised he did that > JL: openswan doesn't use native ipsec either > CH: it does now > JN: he said if he didn't use pfkey symmantics he didn't see it. I > wasn't > sure > CH: I think this can't be fixed . if you use netlink > JL: regardless of socket API .. shouldn't be the same > CH: I think we still do... > JN: james said he had patch which fixes blocking packet. even if > it is 60 or > 80% solution, it is better than nothing. In our solution I put a > check > and just make it try again, but this is not a solution for 3rd party > tools > JA: we can put that in glibc. obviously not the right thing to do > GW: if we don't do anything, labeled ipsec solution will be useless > JN: I think it'll be problematic. > CH: It is not completely useless. it does work, but just has > initial setup > problem > GW: I think most people are setting VPN tunnels > IB: is there a defect number. > JL: I'll open one now > IB: there are 2 that I can see but not what you are discussing > GW: joy will open a bug today. Thanks Joy. I am thinking what is > this going > to mean for certification. > JL: it will be problematic > SG: what we need is to get bug open and I'll get that to kernel > managers and > see who we can get assigned to it. > JL: ok, I'll open a bug now and mail number on lspp list > GW: is there some hope that we can fix this for cert > JA: if we have to we can input that in glibc > SG: not sure they would let us do that though > JA: yeah. just if we have to > SG: start with a bug and I'll talk to kernel managers. once we > have estimate > we'll decide. > LK: are you going to open bug for no prompt on first boot george > GW: yes, I wasn't sure first if it was a real bug > JN: I think this packet dropped discussion is good > LK: what kernel are you running Joe > JN: we have .63 and hacked up version to make racoon work with > local host > > Self tests / aide > ================= > GW: I've done nothing since last week. been trying to get runcon > transitions > to work, not able to get that to happen from python. > MA: is runcon supposed to work in mls policy > GW: it should if you give it sufficient policy. another process is > to have > processes running at high and low beforehand > DW: it would work if you are changing your policy. so it runs on > command > line, but not in the python > GW: i get invalid context .. > DW: how are you doing exec in python > GW: os.system > PM: I wonder if that invalid context is cause of your problem > GW: I can do it on command line .. > PM: wonder if you are getting bit by that translation problem > MA: you are using system high and low right, not messing with weird > combinations. > GW: yeah .. I think if I give perms to use everything, then it > should have > permission > PM: does python have its own domain > DW: no > LK: there was some stuff on selinux about python recently > GW: fact that says it can't write to /tmp file is weird > JA: is that on .. > DW: is python throwing an exception > GW: no it is what get puts on stderr. I feel it is coming from runcon > MA: is your runcon still bin_t > CH: further testing of translation .. it seems A,B doesn't translate > backward... there is old definition we had compartment problem. it > seems > translation daemon had smart in it to make A,B valid. > KW: there are 2 things AB is specific translation, which is not > good idea if > you have to define each combination. second issue is in forward it > translates A,B but in backward it can't translate, I expect them > to be > reversible > GW: anything else? ok .. we'll adjourn. I'll post self test > results see if > anyone sees any issues. Thank you all. > > Cron > ==== > > Bugs / remaining tasks > ====================== > > Final cutoff date > ================== > > -- > redhat-lspp mailing list > redhat-lspp at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-lspp > From linda.knippers at hp.com Thu Feb 1 17:31:07 2007 From: linda.knippers at hp.com (Linda Knippers) Date: Thu, 01 Feb 2007 12:31:07 -0500 Subject: [redhat-lspp] LSPP Development Telecon 01/29/2007 Minutes In-Reply-To: <45C22288.50703@gmail.com> References: <45C0C013.5040206@us.ibm.com> <45C22288.50703@gmail.com> Message-ID: <45C223DB.8000900@hp.com> Ted X Toth wrote: > I think there was a discussion about naming of polyinstantiated > directories that didn't make it into the notes. The part of the discussion I remember is in the notes. It starts with "MA: and what about changing your translated file". > I don't remember all of > the details of that discussion but I have submitted a pam_namespace > patch and I'm just curious as to whether some version of it is going to > make it into RHEL5? What does your patch do and where was it posted? I don't recall seeing it. -- ljk > > Ted > > Loulwa Salem wrote: > >> I think I confused voices in these notes, so feel free to correct me >> if I attributed something to you that you didn't say. >> >> 01/29/2007 lspp Meeting Minutes: >> =============================== >> Attendees >> >> George Wilson (IBM) - GW >> Lawrence Wilson (IBM) - LW >> Kris Wilson (IBM) - KEW >> Loulwa Salem (IBM) - LS >> Michael Thompson (IBM) - MT >> Joy Latten (IBM) - JL >> Kylene J Hall (IBM) - KH >> Irina Boverman (Red Hat) - IB >> Steve Grubb (Red Hat) - SG >> Dan Walsh (Red Hat) - DW >> James Antill (Red Hat) - JA >> Lisa Smith (HP) - LMS >> Linda Knippers (HP) - LK >> Matt Anderson (HP) - MA >> Paul Moore (HP) - PM >> Klaus Weidner (Atsec) - KW >> Chad Hanson (TCS) - CH >> Joe Nall - JN >> Ted Toth - TT >> >> Tentative Agenda: >> >> Kernel / Beta / rawhide update >> =============================== >> GW: Thank you Paul for the loopback fix patch >> PM: Was joy gonna do stress testing on that. I want to stress it >> is a proof >> of concept patch so probably there is stuff missing. I posted that to >> spur some discussion. It won't surprise me if it breaks once you test >> with it >> JL: I am hoping for good results >> PM: I noticed other issues other than racoon. The SA in phase two, >> there is >> no directionality since src and dst address are the same, it is >> unusual >> so I don't know the ramifications of that. >> JL: I looked at your code and it is the same places I was looking >> at. when I >> was playing with manual stuff, I only needed one SA and it didn't >> need >> direction. I had 1 SA and it worked both ways. so i think it's >> going to >> be ok >> PM: only thing that concerns me is sequence number and window. it is >> loopback so you are guaranteed delivery >> JL: I'll look at seq number. To be honest, I'm thinking who cares >> about seq >> number on loopback. but I'll look. I think seq number was to make >> sure >> we are not forging packets >> PM: if there are lots of senders and receivers, what happens in >> that window >> will we have packet loss >> JL: I'll look at that. To be honest I'm not sure we need to be >> concerned. I >> think seq number is optional sometimes that's why I'm saying it might >> not matter. So let's just make sure >> PM: Ok thank you >> GW: that's extremely good for everybody .thanks Paul. How is >> current kernel >> looking >> LS: it's good I'm using it. I have not seen any problems so far >> GW: how is networking >> JL: yes, it's looking good for me too >> GW: with current policy and 18 kickstart, if I applied updated >> packages >> during post install phase system rebooted instead of panic-ing, so >> it's >> good. Now I don't get console login prompt. I'll look at that more. I >> don't see AVC either. anyone else not seen console prompt? >> LK: I've seen that problem on ia64 on first boot. just on the console >> PM: I think I've seen it as well >> DW: is there a getty for that >> GW: there is a getty on console as far as I can tell. I'll look >> into it >> more. >> DW: 2 things to check, check the getty and check the device is >> labeled >> correctly. >> GW: good point since it is a hvc0 >> DW: it might be problem ... >> GW: I'll look into that since this is a virtual console >> LK: if you reboot system, it'll be fine .. that's why it's weird. >> I went to >> single user mode and it came back >> DW: the console came back >> LK: yes, also even though you don't get prompt, I can still log in >> to the >> system >> JA: when this happens is it running first boot graphical? >> GW: I don't think so. is it even running on first boot? >> JA: depends on your kickstart >> MA: if it is a java console ... >> KW: I've run it on VM ware and I don't see that, so I don't think >> it is >> related to that. >> LK: I'll try to reproduce >> GW: I tried to look at AVC . on first boot you can't log in as admin >> anywhere. so it becomes alot more of pain. but we are making >> progress we >> can reboot without panic-ing. Any other issues? >> >> SELinux base and MLS policy update >> ================================== >> GW: Any policy issues >> DW: we have to find out why some of you are not able to ssh as >> some roles >> KW: seems to be related to translation, if I comment that out it >> works. >> what's happening is that it has separate categories for A and B >> and it >> combines them. it doesn't like that sometimes >> DW: you added that to bugzilla? cause I'll look at it >> KW: I didn't see the bugzilla, I added that to the mailing list >> MA: there were other categories that worked .. weren't those >> merged together >> KW: it wasn't doing that with some others >> DW: if I have two categories defined it translates the entire string >> KW: I think it would make sense to give translation to each label. >> if it is >> supposed to do that then it should work >> DW: you still need to do it for each sensitivity, which is more >> than desired >> KW: people at lower level don't need to see higher levels. It gets >> translated, but other libraries don't agree on syntax >> LK: can someone log in with raw context? should they be able to >> KW: translation should be at user interface level. I am slightly >> surprised, >> it is using sometimes the translated and sometimes the raw context >> DW: I'll look into it now that I have more info >> KW: mostly it is related to specific ones. >> DW: library might be broken >> KW: might be too late to change that. I feel more comfortable if >> tools use >> the translated level all the time >> DW: everything should be translated to raw >> KW: be careful when you are testing that because successful and >> unsuccessful >> ssh attempt look ok >> GW: so you are advocating not being able to use translation on login >> KW: should be a convenience but not affect security >> MT: what's the fallout >> KW: ... >> DW: maybe ssh is broken, I'll figure out what's going on >> MT: just for my info. going forward there was talk about defining >> categories, individual components but not entire context. Is that >> still >> the case? >> CH: that would be wonderful. >> MT: the permutations get big, so I see that as being useful >> DW: is A,B the same as B,A >> MT: should be sanitized. categories are independent listing >> CH: raw context has to be same >> PM: question are the compartments related to each other if c1 c2 >> c7 are >> set, by convention they will display to user in order >> DW: access decision is fine >> KW: currently it allows us to give range of categories. if someone >> comes >> along and renumbers things, a tool might include things that you >> might >> not have expected. admin shouldn't use category ranges >> DW: I don't think you can use ranges. only reason I say this is >> that the >> whole system would break. there is way to translate and it can >> definitely use smarter engine >> MA: and what about changing your translated file >> KW: polyinstantiation uses translated labels. it is something >> people need to >> be aware of that their home dirs may go away. >> MT: it should be changed to use raw >> PM: there was same discussion for s-tar. stephen smalley came out >> and said >> he likes translated context than raw since it makes more sense >> CH: it might make sense especially if you have different numbering >> schema >> JN: polyinstantiated dirs used to translate names .. >> JA: do we have any translation which have / in them >> JN: in the us government on labels it has / all over the place >> LK: is there a need to have context as part of directory name >> MA: this came up in last SELinux symposium. >> JA: that should give you usability plus it is guaranteed unique >> GW: hashed would be safest >> PM: I understand this is convenient but how often is it done >> KW: there is no reason why security user logged in as secret can't >> read his >> unclassified dir. >> LK: if you check file level will you get full context >> KW: kickstart uses level and category to set up polyinstantiation >> not full >> context. it doesn't need to be fully unique. it's a nice thing it >> doesn't polyinstantiate based on user name. >> JA: .. >> KW: my gut feeling is keep it way it is with translated format. >> raw format has problems >> JW: right we don't want to move everything to raw >> KW: especially for tools ... it would be better if they use ... >> CH: if old setrans file tried to concatenate A and B together... >> KW: there are 2 different definitions >> CH: translation library says there is no match, so I'll take A and >> B and put >> comma between them. >> KW: if it uses syntax with commas I expect that to pass >> CH: I would expect that to fail if it can't translate >> KW: seems it can't translate back >> GW: Other issues? >> JL: kylie , lou and I saw we can't so ssh as secadm .. is there a >> boolean >> for that? >> DW: there is a boolean. you can't specify to secadm? >> KH: I'll check on that >> KW: isn't secadm deprecated in this policy? >> DW: might be a policy issue >> GW: should we expect them to be deprecated >> KW: it is not possible for sysadm to start setrans daemon in >> enforcing. >> DW: did you run through init? >> KW: yes. I'll send an email >> PM: maybe because it runs as systemHigh >> KH: auditadm works ok, but not secadm.. wait I wasn't in enforcing >> JL: sysadm only works, secadm and auditadm doesn't >> DW: ok, it should be an easy fix. >> JN: has joy changes made it to latest policy? >> DW: I put them in latest >> JL: I sent patch so setkey can look at directories. I sent you >> patch so >> setkey can't look in user home dirs for config files and such. >> DW: where is user likely to create these things? >> JL: I don't know where. I figured setkey should only run as >> sysadm, so I >> don't need to be looking in user directories. SO I changed it to >> look in >> sysadm user dir, /etc/ and maybe /tmp >> DW: Ok, I saw the patch. I'll take another look at it >> KW: problem with setrans, if you use runinit it doesn't seem to >> know there >> are others running, so it creates another one. It seems to have a pid >> file. >> DW: if you say run-init status what does it show you? >> KW: shows stopped >> DW: so it is not seeing pid file. what is label on pid file >> KW: systemhigh >> PM: what happens if you try to query if you are at systemhigh >> KW: I get no such file or directory for pid file. >> >> PAM and VFS polyinstantiation >> ============================== >> >> ssh level selection >> ==================== >> >> IPsec localhost, IPv6, 1st packet drop >> ====================================== >> GW: talked about most of networking. first packet drop is not >> going to get >> fixed anytime soon since it is a big fix. I am wondering the >> ramifications >> JN: I think it is a big impact >> JN: there was email with james morris and he said he had a patch >> but it >> wasn't ready for prime time. he said I should use openswan. I was >> surprised he did that >> JL: openswan doesn't use native ipsec either >> CH: it does now >> JN: he said if he didn't use pfkey symmantics he didn't see it. I >> wasn't >> sure >> CH: I think this can't be fixed . if you use netlink >> JL: regardless of socket API .. shouldn't be the same >> CH: I think we still do... >> JN: james said he had patch which fixes blocking packet. even if >> it is 60 or >> 80% solution, it is better than nothing. In our solution I put a >> check >> and just make it try again, but this is not a solution for 3rd party >> tools >> JA: we can put that in glibc. obviously not the right thing to do >> GW: if we don't do anything, labeled ipsec solution will be useless >> JN: I think it'll be problematic. >> CH: It is not completely useless. it does work, but just has >> initial setup >> problem >> GW: I think most people are setting VPN tunnels >> IB: is there a defect number. >> JL: I'll open one now >> IB: there are 2 that I can see but not what you are discussing >> GW: joy will open a bug today. Thanks Joy. I am thinking what is >> this going >> to mean for certification. >> JL: it will be problematic >> SG: what we need is to get bug open and I'll get that to kernel >> managers and >> see who we can get assigned to it. >> JL: ok, I'll open a bug now and mail number on lspp list >> GW: is there some hope that we can fix this for cert >> JA: if we have to we can input that in glibc >> SG: not sure they would let us do that though >> JA: yeah. just if we have to >> SG: start with a bug and I'll talk to kernel managers. once we >> have estimate >> we'll decide. >> LK: are you going to open bug for no prompt on first boot george >> GW: yes, I wasn't sure first if it was a real bug >> JN: I think this packet dropped discussion is good >> LK: what kernel are you running Joe >> JN: we have .63 and hacked up version to make racoon work with >> local host >> >> Self tests / aide >> ================= >> GW: I've done nothing since last week. been trying to get runcon >> transitions >> to work, not able to get that to happen from python. >> MA: is runcon supposed to work in mls policy >> GW: it should if you give it sufficient policy. another process is >> to have >> processes running at high and low beforehand >> DW: it would work if you are changing your policy. so it runs on >> command >> line, but not in the python >> GW: i get invalid context .. >> DW: how are you doing exec in python >> GW: os.system >> PM: I wonder if that invalid context is cause of your problem >> GW: I can do it on command line .. >> PM: wonder if you are getting bit by that translation problem >> MA: you are using system high and low right, not messing with weird >> combinations. >> GW: yeah .. I think if I give perms to use everything, then it >> should have >> permission >> PM: does python have its own domain >> DW: no >> LK: there was some stuff on selinux about python recently >> GW: fact that says it can't write to /tmp file is weird >> JA: is that on .. >> DW: is python throwing an exception >> GW: no it is what get puts on stderr. I feel it is coming from runcon >> MA: is your runcon still bin_t >> CH: further testing of translation .. it seems A,B doesn't translate >> backward... there is old definition we had compartment problem. it >> seems >> translation daemon had smart in it to make A,B valid. >> KW: there are 2 things AB is specific translation, which is not >> good idea if >> you have to define each combination. second issue is in forward it >> translates A,B but in backward it can't translate, I expect them >> to be >> reversible >> GW: anything else? ok .. we'll adjourn. I'll post self test >> results see if >> anyone sees any issues. Thank you all. >> >> Cron >> ==== >> >> Bugs / remaining tasks >> ====================== >> >> Final cutoff date >> ================== >> >> -- >> redhat-lspp mailing list >> redhat-lspp at redhat.com >> https://www.redhat.com/mailman/listinfo/redhat-lspp >> > > -- > redhat-lspp mailing list > redhat-lspp at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-lspp From txtoth at gmail.com Thu Feb 1 18:29:16 2007 From: txtoth at gmail.com (Ted X Toth) Date: Thu, 01 Feb 2007 12:29:16 -0600 Subject: [redhat-lspp] LSPP Development Telecon 01/29/2007 Minutes In-Reply-To: <45C223DB.8000900@hp.com> References: <45C0C013.5040206@us.ibm.com> <45C22288.50703@gmail.com> <45C223DB.8000900@hp.com> Message-ID: <45C2317C.3020702@gmail.com> Linda Knippers wrote: > Ted X Toth wrote: > >> I think there was a discussion about naming of polyinstantiated >> directories that didn't make it into the notes. >> > > The part of the discussion I remember is in the notes. It starts with > "MA: and what about changing your translated file". > > Ok, seemed like there was more but maybe I was just dreaming. >> I don't remember all of >> the details of that discussion but I have submitted a pam_namespace >> patch and I'm just curious as to whether some version of it is going to >> make it into RHEL5? >> > > What does your patch do and where was it posted? I don't recall seeing it. > I sent it to Dan who forwarded it to this list on 1/24. The email with subject "pam_namespace patch" contains the patch and describes it. > -- ljk > >> Ted >> >> Loulwa Salem wrote: >> >> >>> I think I confused voices in these notes, so feel free to correct me >>> if I attributed something to you that you didn't say. >>> >>> 01/29/2007 lspp Meeting Minutes: >>> =============================== >>> Attendees >>> >>> George Wilson (IBM) - GW >>> Lawrence Wilson (IBM) - LW >>> Kris Wilson (IBM) - KEW >>> Loulwa Salem (IBM) - LS >>> Michael Thompson (IBM) - MT >>> Joy Latten (IBM) - JL >>> Kylene J Hall (IBM) - KH >>> Irina Boverman (Red Hat) - IB >>> Steve Grubb (Red Hat) - SG >>> Dan Walsh (Red Hat) - DW >>> James Antill (Red Hat) - JA >>> Lisa Smith (HP) - LMS >>> Linda Knippers (HP) - LK >>> Matt Anderson (HP) - MA >>> Paul Moore (HP) - PM >>> Klaus Weidner (Atsec) - KW >>> Chad Hanson (TCS) - CH >>> Joe Nall - JN >>> Ted Toth - TT >>> >>> Tentative Agenda: >>> >>> Kernel / Beta / rawhide update >>> =============================== >>> GW: Thank you Paul for the loopback fix patch >>> PM: Was joy gonna do stress testing on that. I want to stress it >>> is a proof >>> of concept patch so probably there is stuff missing. I posted that to >>> spur some discussion. It won't surprise me if it breaks once you test >>> with it >>> JL: I am hoping for good results >>> PM: I noticed other issues other than racoon. The SA in phase two, >>> there is >>> no directionality since src and dst address are the same, it is >>> unusual >>> so I don't know the ramifications of that. >>> JL: I looked at your code and it is the same places I was looking >>> at. when I >>> was playing with manual stuff, I only needed one SA and it didn't >>> need >>> direction. I had 1 SA and it worked both ways. so i think it's >>> going to >>> be ok >>> PM: only thing that concerns me is sequence number and window. it is >>> loopback so you are guaranteed delivery >>> JL: I'll look at seq number. To be honest, I'm thinking who cares >>> about seq >>> number on loopback. but I'll look. I think seq number was to make >>> sure >>> we are not forging packets >>> PM: if there are lots of senders and receivers, what happens in >>> that window >>> will we have packet loss >>> JL: I'll look at that. To be honest I'm not sure we need to be >>> concerned. I >>> think seq number is optional sometimes that's why I'm saying it might >>> not matter. So let's just make sure >>> PM: Ok thank you >>> GW: that's extremely good for everybody .thanks Paul. How is >>> current kernel >>> looking >>> LS: it's good I'm using it. I have not seen any problems so far >>> GW: how is networking >>> JL: yes, it's looking good for me too >>> GW: with current policy and 18 kickstart, if I applied updated >>> packages >>> during post install phase system rebooted instead of panic-ing, so >>> it's >>> good. Now I don't get console login prompt. I'll look at that more. I >>> don't see AVC either. anyone else not seen console prompt? >>> LK: I've seen that problem on ia64 on first boot. just on the console >>> PM: I think I've seen it as well >>> DW: is there a getty for that >>> GW: there is a getty on console as far as I can tell. I'll look >>> into it >>> more. >>> DW: 2 things to check, check the getty and check the device is >>> labeled >>> correctly. >>> GW: good point since it is a hvc0 >>> DW: it might be problem ... >>> GW: I'll look into that since this is a virtual console >>> LK: if you reboot system, it'll be fine .. that's why it's weird. >>> I went to >>> single user mode and it came back >>> DW: the console came back >>> LK: yes, also even though you don't get prompt, I can still log in >>> to the >>> system >>> JA: when this happens is it running first boot graphical? >>> GW: I don't think so. is it even running on first boot? >>> JA: depends on your kickstart >>> MA: if it is a java console ... >>> KW: I've run it on VM ware and I don't see that, so I don't think >>> it is >>> related to that. >>> LK: I'll try to reproduce >>> GW: I tried to look at AVC . on first boot you can't log in as admin >>> anywhere. so it becomes alot more of pain. but we are making >>> progress we >>> can reboot without panic-ing. Any other issues? >>> >>> SELinux base and MLS policy update >>> ================================== >>> GW: Any policy issues >>> DW: we have to find out why some of you are not able to ssh as >>> some roles >>> KW: seems to be related to translation, if I comment that out it >>> works. >>> what's happening is that it has separate categories for A and B >>> and it >>> combines them. it doesn't like that sometimes >>> DW: you added that to bugzilla? cause I'll look at it >>> KW: I didn't see the bugzilla, I added that to the mailing list >>> MA: there were other categories that worked .. weren't those >>> merged together >>> KW: it wasn't doing that with some others >>> DW: if I have two categories defined it translates the entire string >>> KW: I think it would make sense to give translation to each label. >>> if it is >>> supposed to do that then it should work >>> DW: you still need to do it for each sensitivity, which is more >>> than desired >>> KW: people at lower level don't need to see higher levels. It gets >>> translated, but other libraries don't agree on syntax >>> LK: can someone log in with raw context? should they be able to >>> KW: translation should be at user interface level. I am slightly >>> surprised, >>> it is using sometimes the translated and sometimes the raw context >>> DW: I'll look into it now that I have more info >>> KW: mostly it is related to specific ones. >>> DW: library might be broken >>> KW: might be too late to change that. I feel more comfortable if >>> tools use >>> the translated level all the time >>> DW: everything should be translated to raw >>> KW: be careful when you are testing that because successful and >>> unsuccessful >>> ssh attempt look ok >>> GW: so you are advocating not being able to use translation on login >>> KW: should be a convenience but not affect security >>> MT: what's the fallout >>> KW: ... >>> DW: maybe ssh is broken, I'll figure out what's going on >>> MT: just for my info. going forward there was talk about defining >>> categories, individual components but not entire context. Is that >>> still >>> the case? >>> CH: that would be wonderful. >>> MT: the permutations get big, so I see that as being useful >>> DW: is A,B the same as B,A >>> MT: should be sanitized. categories are independent listing >>> CH: raw context has to be same >>> PM: question are the compartments related to each other if c1 c2 >>> c7 are >>> set, by convention they will display to user in order >>> DW: access decision is fine >>> KW: currently it allows us to give range of categories. if someone >>> comes >>> along and renumbers things, a tool might include things that you >>> might >>> not have expected. admin shouldn't use category ranges >>> DW: I don't think you can use ranges. only reason I say this is >>> that the >>> whole system would break. there is way to translate and it can >>> definitely use smarter engine >>> MA: and what about changing your translated file >>> KW: polyinstantiation uses translated labels. it is something >>> people need to >>> be aware of that their home dirs may go away. >>> MT: it should be changed to use raw >>> PM: there was same discussion for s-tar. stephen smalley came out >>> and said >>> he likes translated context than raw since it makes more sense >>> CH: it might make sense especially if you have different numbering >>> schema >>> JN: polyinstantiated dirs used to translate names .. >>> JA: do we have any translation which have / in them >>> JN: in the us government on labels it has / all over the place >>> LK: is there a need to have context as part of directory name >>> MA: this came up in last SELinux symposium. >>> JA: that should give you usability plus it is guaranteed unique >>> GW: hashed would be safest >>> PM: I understand this is convenient but how often is it done >>> KW: there is no reason why security user logged in as secret can't >>> read his >>> unclassified dir. >>> LK: if you check file level will you get full context >>> KW: kickstart uses level and category to set up polyinstantiation >>> not full >>> context. it doesn't need to be fully unique. it's a nice thing it >>> doesn't polyinstantiate based on user name. >>> JA: .. >>> KW: my gut feeling is keep it way it is with translated format. >>> raw format has problems >>> JW: right we don't want to move everything to raw >>> KW: especially for tools ... it would be better if they use ... >>> CH: if old setrans file tried to concatenate A and B together... >>> KW: there are 2 different definitions >>> CH: translation library says there is no match, so I'll take A and >>> B and put >>> comma between them. >>> KW: if it uses syntax with commas I expect that to pass >>> CH: I would expect that to fail if it can't translate >>> KW: seems it can't translate back >>> GW: Other issues? >>> JL: kylie , lou and I saw we can't so ssh as secadm .. is there a >>> boolean >>> for that? >>> DW: there is a boolean. you can't specify to secadm? >>> KH: I'll check on that >>> KW: isn't secadm deprecated in this policy? >>> DW: might be a policy issue >>> GW: should we expect them to be deprecated >>> KW: it is not possible for sysadm to start setrans daemon in >>> enforcing. >>> DW: did you run through init? >>> KW: yes. I'll send an email >>> PM: maybe because it runs as systemHigh >>> KH: auditadm works ok, but not secadm.. wait I wasn't in enforcing >>> JL: sysadm only works, secadm and auditadm doesn't >>> DW: ok, it should be an easy fix. >>> JN: has joy changes made it to latest policy? >>> DW: I put them in latest >>> JL: I sent patch so setkey can look at directories. I sent you >>> patch so >>> setkey can't look in user home dirs for config files and such. >>> DW: where is user likely to create these things? >>> JL: I don't know where. I figured setkey should only run as >>> sysadm, so I >>> don't need to be looking in user directories. SO I changed it to >>> look in >>> sysadm user dir, /etc/ and maybe /tmp >>> DW: Ok, I saw the patch. I'll take another look at it >>> KW: problem with setrans, if you use runinit it doesn't seem to >>> know there >>> are others running, so it creates another one. It seems to have a pid >>> file. >>> DW: if you say run-init status what does it show you? >>> KW: shows stopped >>> DW: so it is not seeing pid file. what is label on pid file >>> KW: systemhigh >>> PM: what happens if you try to query if you are at systemhigh >>> KW: I get no such file or directory for pid file. >>> >>> PAM and VFS polyinstantiation >>> ============================== >>> >>> ssh level selection >>> ==================== >>> >>> IPsec localhost, IPv6, 1st packet drop >>> ====================================== >>> GW: talked about most of networking. first packet drop is not >>> going to get >>> fixed anytime soon since it is a big fix. I am wondering the >>> ramifications >>> JN: I think it is a big impact >>> JN: there was email with james morris and he said he had a patch >>> but it >>> wasn't ready for prime time. he said I should use openswan. I was >>> surprised he did that >>> JL: openswan doesn't use native ipsec either >>> CH: it does now >>> JN: he said if he didn't use pfkey symmantics he didn't see it. I >>> wasn't >>> sure >>> CH: I think this can't be fixed . if you use netlink >>> JL: regardless of socket API .. shouldn't be the same >>> CH: I think we still do... >>> JN: james said he had patch which fixes blocking packet. even if >>> it is 60 or >>> 80% solution, it is better than nothing. In our solution I put a >>> check >>> and just make it try again, but this is not a solution for 3rd party >>> tools >>> JA: we can put that in glibc. obviously not the right thing to do >>> GW: if we don't do anything, labeled ipsec solution will be useless >>> JN: I think it'll be problematic. >>> CH: It is not completely useless. it does work, but just has >>> initial setup >>> problem >>> GW: I think most people are setting VPN tunnels >>> IB: is there a defect number. >>> JL: I'll open one now >>> IB: there are 2 that I can see but not what you are discussing >>> GW: joy will open a bug today. Thanks Joy. I am thinking what is >>> this going >>> to mean for certification. >>> JL: it will be problematic >>> SG: what we need is to get bug open and I'll get that to kernel >>> managers and >>> see who we can get assigned to it. >>> JL: ok, I'll open a bug now and mail number on lspp list >>> GW: is there some hope that we can fix this for cert >>> JA: if we have to we can input that in glibc >>> SG: not sure they would let us do that though >>> JA: yeah. just if we have to >>> SG: start with a bug and I'll talk to kernel managers. once we >>> have estimate >>> we'll decide. >>> LK: are you going to open bug for no prompt on first boot george >>> GW: yes, I wasn't sure first if it was a real bug >>> JN: I think this packet dropped discussion is good >>> LK: what kernel are you running Joe >>> JN: we have .63 and hacked up version to make racoon work with >>> local host >>> >>> Self tests / aide >>> ================= >>> GW: I've done nothing since last week. been trying to get runcon >>> transitions >>> to work, not able to get that to happen from python. >>> MA: is runcon supposed to work in mls policy >>> GW: it should if you give it sufficient policy. another process is >>> to have >>> processes running at high and low beforehand >>> DW: it would work if you are changing your policy. so it runs on >>> command >>> line, but not in the python >>> GW: i get invalid context .. >>> DW: how are you doing exec in python >>> GW: os.system >>> PM: I wonder if that invalid context is cause of your problem >>> GW: I can do it on command line .. >>> PM: wonder if you are getting bit by that translation problem >>> MA: you are using system high and low right, not messing with weird >>> combinations. >>> GW: yeah .. I think if I give perms to use everything, then it >>> should have >>> permission >>> PM: does python have its own domain >>> DW: no >>> LK: there was some stuff on selinux about python recently >>> GW: fact that says it can't write to /tmp file is weird >>> JA: is that on .. >>> DW: is python throwing an exception >>> GW: no it is what get puts on stderr. I feel it is coming from runcon >>> MA: is your runcon still bin_t >>> CH: further testing of translation .. it seems A,B doesn't translate >>> backward... there is old definition we had compartment problem. it >>> seems >>> translation daemon had smart in it to make A,B valid. >>> KW: there are 2 things AB is specific translation, which is not >>> good idea if >>> you have to define each combination. second issue is in forward it >>> translates A,B but in backward it can't translate, I expect them >>> to be >>> reversible >>> GW: anything else? ok .. we'll adjourn. I'll post self test >>> results see if >>> anyone sees any issues. Thank you all. >>> >>> Cron >>> ==== >>> >>> Bugs / remaining tasks >>> ====================== >>> >>> Final cutoff date >>> ================== >>> >>> -- >>> redhat-lspp mailing list >>> redhat-lspp at redhat.com >>> https://www.redhat.com/mailman/listinfo/redhat-lspp >>> >>> >> -- >> redhat-lspp mailing list >> redhat-lspp at redhat.com >> https://www.redhat.com/mailman/listinfo/redhat-lspp >> > > > From linda.knippers at hp.com Fri Feb 2 00:13:22 2007 From: linda.knippers at hp.com (Linda Knippers) Date: Thu, 01 Feb 2007 19:13:22 -0500 Subject: [redhat-lspp] kickstart changes to select capp or lspp configuration Message-ID: <45C28222.1010606@hp.com> Hi Klaus, The changes I made included adding a question into the post part of the kickstart script and renaming/restructuring so some of the files aren't specific to LSPP. I also made the files vendor neutral. This involved patching some files and moving some things around so its hard to generate just one patch file. Attached are the patch files for the individual files that I modified and below you'll see notes on the things I renamed. I've applied these patches to your latest 0.18 ks sources and they seem to work with the rc1 kit. Let me know if you have any questions or don't agree with some of the changes. If IBM doesn't want to go vendor-neutral as far as my change go then maybe we can make it easier to include the vendor name without alot of changes. The ftp location is still vendor-specific, but it probably will need to be. BTW, this is not in the attached patches but I took the --tries=1 argument out of the wget line in the common-post.cfg file. It seems a recent addition but here it causes wget to not be able to get the certification rpm. I had to escape from the script and manually wget it. Why was it added? -- ljk Changed the name of the spec file to remove company and protection profile specifics. Likewise, renamed files and directories. For example: mv lspp-eal4-config-ibm-0.18/bin/lspp-eal4-config.in eal4-config-0.16/bin/eal4-config.in Updated the script to take the profile as an argument. mv lspp-eal4-config-ibm-0.18/doc/RHEL-LSPP-EAL4-IBM-Configuration-Guide.man eal4-config-0.16/doc/RHEL-EAL4-Configuration-Guide.man (this will probably need to go back to being vendor-specific but shouldn't be protection profile specific) mv lspp-eal4-config-ibm-0.18/lspp eal4-config-0.16/eal4 And within that directory: mv lspp-perms.conf eal4-perms.conf mv lspp-root-only.conf eal4-root-only.conf Updated kickstart/src/common-head.cfg with different tmp filenames. Perhaps not necessary. (Would like to make default timezone configurable.) Updated kickstart/src/common-pre.cfg to adjust prompts and file names. Updated kickstart/src/common-post.cfg to adjust prompts and ask for the protection profile. Updated Makefile to refer to new files/directories. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: common-head.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: common-post.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Makefile.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: spec.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: common-pre.patch URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: config.patch URL: From txtoth at gmail.com Fri Feb 2 16:04:43 2007 From: txtoth at gmail.com (Ted X Toth) Date: Fri, 02 Feb 2007 10:04:43 -0600 Subject: [redhat-lspp] [Fwd: pam_namespace patch] In-Reply-To: <1169653247.3335.25.camel@perun.kabelta.loc> References: <45B77A89.1030608@redhat.com> <1169653247.3335.25.camel@perun.kabelta.loc> Message-ID: <45C3611B.5020705@gmail.com> Does someone need to open a bug report for this? Ted Tomas Mraz wrote: > On Wed, 2007-01-24 at 10:26 -0500, Daniel J Walsh wrote: > >> Forwarding this for comment on the redhat-lspp list. >> >> -------- Original Message -------- >> Subject: pam_namespace patch >> Date: Wed, 24 Jan 2007 08:45:27 -0600 >> From: Xavier Toth >> To: dwalsh at redhat.com >> >> >> >> Dan, >> I'm not sure who to send this to because I haven't submitted a patch >> before but you seemed to be a good candidate. The CAPCO security >> labeling standard allows for characters that are both illegal (for >> instance '/') and unsightly in filenames. This patch processes the >> context to generate a more viable filename. It does so by replacing >> unwanted characters with '_'. I put together a list of character to be >> replaced but feel free to alter it. I created the patch against >> Rawhide but hopefully it will work its way into RHEL5. >> > > What about potential collisions created by this? I mean it is perhaps > possible (although probably not common and wise) to have two contexts on > a system having the same name differing only by the special characters. > It must be either properly documented in pam_namespace documentation or > the conversion function must be changed to use a different way how to > translate it (perhaps using an URL encoding %XX format?). > From linda.knippers at hp.com Fri Feb 2 19:35:50 2007 From: linda.knippers at hp.com (Linda Knippers) Date: Fri, 02 Feb 2007 14:35:50 -0500 Subject: [redhat-lspp] LSPP kickstart config v0.18 released In-Reply-To: <20070123131425.GE12994@w-m-p.com> References: <20070123131425.GE12994@w-m-p.com> Message-ID: <45C39296.9060802@hp.com> Hi Klaus, I see that this verison of the ks rpm still has alot of stuff in the lspp policy module (attached for those not using the rpm). Some of the policy changes reference bugzillas but not all of them. Has Dan pulled these changes into the mls policy? -- ljk -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lspp_policy.te URL: From ltcgcw at us.ibm.com Fri Feb 2 23:27:31 2007 From: ltcgcw at us.ibm.com (George C. Wilson) Date: Fri, 2 Feb 2007 17:27:31 -0600 Subject: [redhat-lspp] [Reminder] Open LSPP Development Telecon Mon., Feb. 5 Message-ID: <20070202232731.GA11423@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 txtoth at gmail.com Mon Feb 5 14:33:50 2007 From: txtoth at gmail.com (Ted X Toth) Date: Mon, 05 Feb 2007 08:33:50 -0600 Subject: [redhat-lspp] [Fwd: pam_namespace patch] In-Reply-To: <1170684912.3173.14.camel@perun.kabelta.loc> References: <45B77A89.1030608@redhat.com> <1169653247.3335.25.camel@perun.kabelta.loc> <45C3611B.5020705@gmail.com> <1170684912.3173.14.camel@perun.kabelta.loc> Message-ID: <45C7404E.8020305@gmail.com> I cannot open a bug can someone help me? Tomas Mraz wrote: > On Fri, 2007-02-02 at 10:04 -0600, Ted X Toth wrote: > >> Does someone need to open a bug report for this? >> > Please open that if you can. > > From tmraz at redhat.com Mon Feb 5 15:07:35 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 05 Feb 2007 16:07:35 +0100 Subject: [redhat-lspp] [Fwd: pam_namespace patch] In-Reply-To: <45C7404E.8020305@gmail.com> References: <45B77A89.1030608@redhat.com> <1169653247.3335.25.camel@perun.kabelta.loc> <45C3611B.5020705@gmail.com> <1170684912.3173.14.camel@perun.kabelta.loc> <45C7404E.8020305@gmail.com> Message-ID: <1170688055.3173.16.camel@perun.kabelta.loc> On Mon, 2007-02-05 at 08:33 -0600, Ted X Toth wrote: > I cannot open a bug can someone help me? > > Tomas Mraz wrote: > > On Fri, 2007-02-02 at 10:04 -0600, Ted X Toth wrote: > > > >> Does someone need to open a bug report for this? > >> > > Please open that if you can. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227345 -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From loulwas at us.ibm.com Tue Feb 6 16:14:04 2007 From: loulwas at us.ibm.com (Loulwa Salem) Date: Tue, 06 Feb 2007 10:14:04 -0600 Subject: [redhat-lspp] LSPP Development Telecon 02/05/2007 Minutes Message-ID: <45C8A94C.5000609@us.ibm.com> 02/05/2007 lspp Meeting Minutes: =============================== Attendees George Wilson (IBM) - GW Lawrence Wilson (IBM) - LW Kris Wilson (IBM) - KEW Loulwa Salem (IBM) - LS Debora Velarde (IBM) - DV Michael Thompson (IBM) - MT Joy Latten (IBM) - JL Kylene J Hall (IBM) - KH Irina Boverman (Red Hat) - IB Steve Grubb (Red Hat) - SG Dan Walsh (Red Hat) - DW Eric Paris (Red Hat) - EP Lisa Smith (HP) - LMS Linda Knippers (HP) - LK Matt Anderson (HP) - MA Paul Moore (HP) - PM Klaus Weidner (Atsec) - KW Chad Hanson (TCS) - CH Joe Nall - JN Ted Toth - TT Bill O'Donnel - BO Tentative Agenda: Kernel / Beta / rawhide update =============================== GW: we are still waiting for a few more people LK: while waiting, Klaus you took autorelabel out of kickstart script, and now I see problems with the labels KW: haven't seen those. Apparently there should not be need to relabel twice, we should look into why it is wrong in the first place. LK: labels on /root and home directory doesn't work GW: how do you know it is not relabeled? LK: if you relabel, it shows they are being relabeled again different than what it was. MA: I saw a similar problem with /home directory also KW: individual home directories? LK: yes KW: it uses user management tools. In previous version, it did a relabel after that. LK: there was a bugzilla where adduser and semanage are two different tools DW: how are you adding user? LK: useradd KW: I need to read docs on that DW: use useradd -z and that should get file context correctly. what context are you getting on home directories? MA: user for ones that should be staff I think. LK: I filed bugzilla specifically on /root. I think we are seeing this now, because the script used to do autorelabel again and now it doesn't DW: how are you relabeling in the kickstart.. using fixfiles? KW: fixfile -f DW: that might be a problem. I think it does not touch user home directories KW: they don't exist at that point yet LK: but /root should KW: currently it uses useradd then semanage login DW: you can't reverse those, but use useradd -z KW: how about the -m flag to modify in semanage DW: you can use semanage afterwards, the labeling on home directories shouldn't affect that. if root directory is not fixed by fixfile then restore that directory KW: I used restorecon on individual files LK: that's what I did as a work around MA: can you do that on /home as well KW: yes, ok LK: should have been created as part of install? DW: sysadm needs to relabel. GW: alright ... so other issues with kickstart, build or kernel. I presume we still need lspp kernel, and we have to force install it. SG: yes. from this point you will use lspp kernels. I think there will be at least .65 EP: what do you mean you have to force install it LS: it says current kernel is newer than what you are trying to install. SG: I will look at it. EP: what kernel were you using originally? GW: the latest 01/26 I think EP: I'll look at it SG: we will have opportunities to build new kernels. we'll clean it up for the new patches. GW: so kernel, policy and mcstrans are only packages that need to be installed SG: you're talking about snapshot GW: release candidate is what they call it here SG: I'll get everything into lspp repo to streamline GW: I was suggesting we keep list of packages we need SG: I was gonna suggest we revise this teleconference to be listing of bugzilla. development is finished and we are focusing on bugzillas now. if anything new comes up it should become bugzilla to get on the agenda. GW: is everyone fine with that SG: Irena has a way to track bugzilla and we can collect everything we need to talk about. Based on that bug, I'll track what needs to go in the repo GW: do you want to start that today? LW: is it going to be tabular format or text GW: this is the list that Irena created for us LW: are we going to have a list or tabular format IB: I'll have a list of bugs. I'll send it Friday night and George can re-publish for the meeting GW: we'll work from Irena's list and any new issues that people want to talk about we can add that. SG: there will always be discussion about using the system. I think we are at a point now to start going over bugs. LK: there is even bugzilla for one just discussed. IB: I was thinking we can use partner server for packages. I was looking at repository for that. SG: when we get close to end, we'll put it there IB: ... GW: from what I am hearing .. Steve you will provide repo off your people page then near the end it will be put on partner site so we can verify it SG: yes, I started cleaning lspp repo. this week I should be able to collect everything and get scripts to automate pushing packages there. SELinux base and MLS policy update ================================== IPsec localhost, IPv6, 1st packet drop ====================================== GW: I have bug a list infront of me, I can hit some bugs while having this discussion. one of them is labeled ipsec does not work over loopback JL: I tested with it, regression and stress test went well. Only thing I saw was the error message occurred every time an SA had to be re-keyed. I need to look into why that is happening. Paul won't have time to doctor the patch, when I have time, I'll look at it. if I can fix it then I'll go ahead and submit to ipsec tools list GW: Another issue, problem ssh into lspp system with multiple categories, Dan posted mcstransd for that. Also, ipsec drops first packet (bug # 225328) JL: David miller put a patch and james miller is happy with it. he has v4 and v6 version for it, so I'll try it SG: patch I saw on netdev looked like it had bug in it. looks like he created flag variable but not sure if flag got used JL: he just posted message PM: Steve he fixed that. JL: he put updated version in net-2.26 tree. I'll take the patch and patch our lspp kernel and see what happens. I don't know if I should test on lspp or upstream first GW: probably both JL: I'll test lspp kernel first and tell him because of priority issues. unless I can do both at same time on two different machines. SG: let us know and I'll go ahead and get a .65 kernel so everyone can test JL: ok, I'll do that GW: so is 224637 a duplicate of 225355 (labeled translation causing ssh login failure)? DW: same problem GW: ok, so I'll remove one SG: I think Eric Paris found duplicate bug on msgqueue EP: don't think they are duplicate, but same patch should fix both issues. GW: anything else on networking JL: nothing right now. stress test is ok. I tested loopback and labeled ipsec with v6. I'll continue from there. Self tests / aide ================= GW: As for the self tests. my approach won't work, what I am thinking is having two instances one at systemhigh and another at systemlow and have them independently. Anyone has better approach. The runcon approach is basically trying to validate context. I can newrole into the context but can't get to it non interactively through runcon LK: what are you trying to test? GW: BLP which is a good thing that it won't let me. I want to be systemlow, write a file and verify I can read it at sytemhigh but inverse is not true. LK: does it have to be a file you created. maybe you can be at middle level and try to read/write files already existing GW: I could do that and have one time setup and create files then execute against them. I found that changing levels is difficult. I will have to do file setup ahead of time LK: when talking to dan about runcon before, he suggested using newrole with it. would that work? GW: I still need a password DW: You could set newrole_pam root_ok to avoid needing password GW: I think we don't want to do that though KW: I think from evaluation point of view it's ok, we assume trusted admins MA: doesn't root_ok only take affect if it is coming from sysadm_r. so it's not a big hole as we thought initially DW: yes LK: what does Joe think DW: all the test you are trying to do is 2 different processes running at 2 different levels can't communicate ... right? GW: yes DW: I think the bi-level would work GW: I was trying to do that JN: that seems to work for me, sorry I checked out looking at some patches DW: I think we can write policy to have 2 init script to do this GW: so you use init to start them off DW: have two init, one that transitions to systemhigh and one that stays low, and have them communicate GW: I think this is what will work. I feel current approach won't work. I'll try the split approach then. SG: how will they communicate? GW: sockets, signals or files. I was trying to make it simple and throw it out there for people to see. SG: I think if you use abstract namespace then there is no chance of someone being able to tamper with files JN: can you explain that, I don't understand the abstract namespace SG: the abstract name space will only be accessible to the processes only GW: unnamed things instead of named things. sockets would work DW: I was thinking systemlow opens listening socket and another one tries to open socket as systemhigh, and read temp files GW: right, if I can get approach working we can test multiple things SG: is /tmp going to have problems with polyinstantiation? GW: I put them in /var/run .. do you think that is abusable SG: I remember the amtu that caused problem KW: /var/run is restricted to root, so I think exposure is pretty small GW: that's what I was thinking. I'll try that and let people look at it. if you have other ways or additional things we can add. The approach needs to be fixable. I'll try that. if Stephan is around I'll ask him what he thinks about it. Then I have to decide how to invoke aide from that. Might have 3 separate tests. it won't be a nice clean simple script as I hoped for DW: you can do all of them from same initscript JN: is this going to run on boot or periodically GW: both. to satisfy RBACPP self test requirements SG: I think it will be a cron job. JN: ok, then cron. is there specific requirements for RBAC or is it open? GW: it is open, but I think we should make it useful. basically we check to make sure configuration is ok and we use aide to do that. KW: I think at lease it needs to check if we are in non enforcing mode or if policy is not loaded. GW: I'll use aide separately. would it be possible to use init in cron job to invoke this, or should we have them as long running processes .. if so I need to get timing variables in there EP: I think it needs to be cron from what you are saying LK: can amtu be there also and you can choose to run it if you want SG: I was thinking to have it something that is run on demand and people can set it to run as they need. GW: it is supposed to be runnable on demand. but also periodically. LK: it can be periodic if they want also SG: I think that's what amtu does GW: do you list a sample cron job for it. MA: I don't think amtu lists a sample cron entry GW: want to make sure we don't have multiple instances running at same time SG: I think there is a locking bug fix to make that work better, but I don't think we are protected from database issues GW: I have to make sure I don't run multiple instances ... MA: there is a built in functionality for the pid files GW: yeah, I can use that for sure. sounds like splitting it into 3 parts is only workable solution. let me try that and I'll see SG: I am confused. we were talking about running on demand and now the init script GW: I was thinking about using init script in cron job and was asking if that is possible DW: yes .. SG: would it have to be turned on? GW: you can run it at boot time.. it doesn't need to be proper init script it just needs to be runnable by initscript DW: we can write policy to have it runnable by sysadm, so it will have one that is at ranges so it can transition to systemhigh GW: ok, that sounds even better .. so probably not init script proper unless somebody decides they want to run at boot time. I'll take what I have, take out aide calls, make it separate test for high and low and that should be the basis.. so we want to go down to other highlight on bug list? SG: yes.. there are a couple ... GW: crontab man pages reference old environment variables. that's probably low priority SG: I need to have the repo take arbitrary packages ... GW: 223532 .. SG: looks like maintainer is looking for direction. I guess he assumes upstream has it right. but it was pointed out upstream behavior is not correct. he needs advice to see if that is what we need. I think last person commented on the bug was klaus kiwi. It is the kind of thing that if behavior is not correct, then a patch should be proposed. GW: who makes that determination, a team of engineers at RH? what is the process? SG: not sure GW: I think it is only a doc fix .. question is do you agree? SG: I don't know I would be willing to bet no one notices ACL list unless they use it. I am just saying that ...[phone problem started] GW: let's talk about bug highlights quickly then before this noise gets worse on the line LK: I have one quick question. klaus there is still some policy for xinetd in lspp policy module is that still needed? KW: I need a test to see if it is. I have a another for lspp mode selection .. LK: I am running without that policy module and not sure what problems I should be looking for KW: we shouldn't need the policy later I think SG: there are 3 audit kernel bugs. I was talking with Al Viro this morning. he was planning to send a backlog of audit patches to Linus tonight. Amy submitted patches for those 3 bugzillas but I was not sure they are ready for upstream. I'm wondering what the status is, is she happy with them to be upstream KL: she is not on, I'll ping here. I think she posted them as untested .. so unless someone else tested them I think they may need work. I'll ask her. SG: I have not seen anyone complaints about that. EP: I pulled them in and tested and they seem ok, but not quite right SG: we have Al's attention to get patches in .21 kernel. I think there is a 2 week merge window EP: yes it is. LK: Eric, do you know of any issue with those patches, and does amy know about them? EP: yes and yes GW: I didn't see anything obvious about console login .. I don't think you did either Linda LK: I couldn't see any debug output for init. I'll try to instrument an init to see if it gets the getty and try that GW: doesn't init have debug output already? LK: I have not seen any. the inittab entry is put before first boot. we only see this in lspp configuration GW: created during first boot? LK: yeah, if I look at it, it is there .. GW: are you seeing the right file LK: maybe I'm looking at wrong one KW: ... GW: I plan on reinstalling this week. LK: I did a kickstart install using the version I modified to set CAPP or lspp mode. The difference is that CAPP mode isn't setting policy and polyinstantiation and in that case it worked. I got console login prompt GW: but no Avc. well .. I plan to install and I guess I'll look at inittab creation process DW: use enable_audit.pp file to see if you get any AVC GW: you have to load that with -b because it is a base module LK: how do you do that? GW: look in /usr/share/selinux for that file DW: use semodule -b enable_audit.pp to see all the suppressed audit messages SG: on irc we were talking on audit -f field not working correctly, so do we want patch to fix that? LK: we were on agreement that it is nice to have. so if you can backport then it'll be good but we don't have a test case to test that. GW: I think at some point we need to stop picking up packages unless it is data corruption or big problems fix GW: we were all in agreement that we like it fixed and we'll pick it up KEW: I have no problem with fixes but new functions will break our tests GW: yes, we need to start locking functionality SG: this is not a functionality but rather a case statement missing which caused problems GW: this we would like to pick up but as we move forward we need to scrutinize what we pick more MA: 223894 bug, that seems to require a patch to introduce audit functionality in cron. LK: Dan did an update for that SG: did you work on that one Dan? DW: I'll check on cron maintainer and see if we have that fix in. GS: so we should expect vixie cron package soon. Until repos are restructured, I'll try to keep list with bugs and packages. we can use that as basis for discussion SG: when bugs change their status to modified that should be removed from discussion, because that means it is fixed and on its way to QA GW: unless it is not fixed or we see problems. we have to drive our bugs to verification status. SG: right, I'm saying that because there have been few people asking what verified means GW: right because they don't map one to one .. like when we close it or we change severity, we have to put notes in bug and the mirroring process is till being worked on on both sides .. just FYI .. the annoying noise on the phone line was not coming from your line Linda :) Bugs / remaining tasks ====================== From klaus at atsec.com Wed Feb 7 06:19:02 2007 From: klaus at atsec.com (Klaus Weidner) Date: Wed, 7 Feb 2007 00:19:02 -0600 Subject: [redhat-lspp] Re: kickstart changes to select capp or lspp configuration In-Reply-To: <45C28222.1010606@hp.com> References: <45C28222.1010606@hp.com> Message-ID: <20070207061902.GA5396@w-m-p.com> On Thu, Feb 01, 2007 at 07:13:22PM -0500, Linda Knippers wrote: > The changes I made included adding a question into the post part of the > kickstart script and renaming/restructuring so some of the files aren't > specific to LSPP. I also made the files vendor neutral. This involved > patching some files and moving some things around so its hard to generate > just one patch file. Attached are the patch files for the individual files > that I modified and below you'll see notes on the things I renamed. Thank you Linda, I'm integrating your patches with changes as noted below. > I've applied these patches to your latest 0.18 ks sources and they seem > to work with the rc1 kit. Let me know if you have any questions or don't agree > with some of the changes. If IBM doesn't want to go vendor-neutral as far > as my change go then maybe we can make it easier to include the vendor name > without alot of changes. It was already parametrized (with some omissions) - the git repository contains the "make-rpm" shell script which builds a source RPM. You can set environment variables before calling "make-rpm" to change names, for example: ECG=ACME-EAL7-Guide NAME=mlospp-eal7-config-acme ./make-rpm 0.19 1 which will result in creating the mlospp-eal7-config-acme-0.19-1.noarch.rpm file. If you put the $ECG.{man,txt,pdf,...} files into the lspp-config/doc/ dir, it'll automatically be added to the RPM in the right place. > The ftp location is still vendor-specific, but it probably will need to > be. This could also be a build time parameter, I haven't done that yet. > BTW, this is not in the attached patches but I took the --tries=1 argument > out of the wget line in the common-post.cfg file. It seems a recent addition > but here it causes wget to not be able to get the certification rpm. I had to > escape from the script and manually wget it. Why was it added? The problem was that without that argument, it retries 20 times to download the file, and pressing Ctrl-C aborts the entire process and forces an immediate reboot. That's really annoying if it failed due to a network or DNS problem since you don't have a chance to fix that. I'll use "--tries=2" this time, is that better? Or is it calling busybox "wget" for some reason which doesn't have that option? (It shouldn't, it's chrooted to the installed system.) What's the error output? > Changed the name of the spec file to remove company and protection profile > specifics. Likewise, renamed files and directories. For example: > > mv lspp-eal4-config-ibm-0.18/bin/lspp-eal4-config.in > eal4-config-0.16/bin/eal4-config.in > Updated the script to take the profile as an argument. I've changed that to use "capp-lspp" instead of "eal4" consistently, so the script name is now "capp-lspp-config". The assurance level is IMHO not particularily descriptive for what the script is doing. > mv lspp-eal4-config-ibm-0.18/doc/RHEL-LSPP-EAL4-IBM-Configuration-Guide.man > eal4-config-0.16/doc/RHEL-EAL4-Configuration-Guide.man > (this will probably need to go back to being vendor-specific but shouldn't > be protection profile specific) You can choose whichever name you like for the ECG and set that in the $ECG variable at build time :-) > mv lspp-eal4-config-ibm-0.18/lspp eal4-config-0.16/eal4 I haven't made that change since it's applicable only to the source RPM, it's not visible in the final install (see Makefile and $SHAREDIR). > And within that directory: > mv lspp-perms.conf eal4-perms.conf > mv lspp-root-only.conf eal4-root-only.conf I've deleted the "eal4-" prefix from those. > Updated kickstart/src/common-head.cfg with different tmp filenames. Perhaps > not necessary. (Would like to make default timezone configurable.) The time zone is changeable after the install. The script could call "tzselect" but I'm not sure if it's worth the effort. Thank you again for the patches! -Klaus From klaus at atsec.com Wed Feb 7 06:49:06 2007 From: klaus at atsec.com (Klaus Weidner) Date: Wed, 7 Feb 2007 00:49:06 -0600 Subject: [redhat-lspp] LSPP kickstart config v0.19 released Message-ID: <20070207064905.GB5396@w-m-p.com> Hello, here's a lightly tested update to go with the recent RC version, and with the CAPP/LSPP mode selection merged (thanks Linda)! Changes: Linda Knippers: Implement CAPP/LSPP profile selection Simplify admin account creation, work around autorelabel $HOME issues Disable bug workaround policies (should no longer be necessary) Run cups as group "lp", ClassifyOverride Yes. See RH BZ#227164 add aide to required pkgs; move cups+ghostscript from optional to req'd pkgs Add pciutils-devel to installed optional packages (needed for tests) Fix sftp server path (thanks Matt Anderson for spotting this) I recommend updating the kernel and mcstrans from http://people.redhat.com/dwalsh/SELinux/RHEL5/ and/or http://people.redhat.com/sgrubb/files/lspp in the postinstall phase, but you can also do this once the system is installed. The installer should work with the plain RC versions. 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 From klaus at atsec.com Wed Feb 7 14:57:15 2007 From: klaus at atsec.com (Klaus Weidner) Date: Wed, 7 Feb 2007 08:57:15 -0600 Subject: [redhat-lspp] LSPP kickstart config v0.19 released In-Reply-To: <20070207064905.GB5396@w-m-p.com> References: <20070207064905.GB5396@w-m-p.com> Message-ID: <20070207145715.GC5396@w-m-p.com> On Wed, Feb 07, 2007 at 12:49:06AM -0600, Klaus Weidner wrote: > here's a lightly tested update to go with the recent RC version, and with > the CAPP/LSPP mode selection merged (thanks Linda)! Sorry, I had forgotten to update the web repository. If you had looked earlier and not seen the new version, please try again now. -Klaus From linda.knippers at hp.com Wed Feb 7 21:16:24 2007 From: linda.knippers at hp.com (Linda Knippers) Date: Wed, 07 Feb 2007 16:16:24 -0500 Subject: [redhat-lspp] Re: kickstart changes to select capp or lspp configuration In-Reply-To: <20070207061902.GA5396@w-m-p.com> References: <45C28222.1010606@hp.com> <20070207061902.GA5396@w-m-p.com> Message-ID: <45CA41A8.3060100@hp.com> Klaus Weidner wrote: >>BTW, this is not in the attached patches but I took the --tries=1 argument >>out of the wget line in the common-post.cfg file. It seems a recent addition >>but here it causes wget to not be able to get the certification rpm. I had to >>escape from the script and manually wget it. Why was it added? > > > The problem was that without that argument, it retries 20 times to > download the file, and pressing Ctrl-C aborts the entire process and > forces an immediate reboot. That's really annoying if it failed due to a > network or DNS problem since you don't have a chance to fix that. > > I'll use "--tries=2" this time, is that better? Or is it calling busybox > "wget" for some reason which doesn't have that option? (It shouldn't, > it's chrooted to the installed system.) What's the error output? I don't recall seeing an error but I don't the output anymore. I'm pretty sure it was calling the right wget. Without the retries option I get a message that tells me that it was try number 2 that worked. HTTP request sent, awaiting response... 200 OK Length: 36763 (36K) [application/x-rpm] --14:49:01-- (try: 2) ... I don't know what's happening on the first try. With your 0.18 script I could never wget the certification rpm without escaping to the shell and manually running wget. How long does 20 retries take? -- ljk From klaus at atsec.com Wed Feb 7 21:41:36 2007 From: klaus at atsec.com (Klaus Weidner) Date: Wed, 7 Feb 2007 15:41:36 -0600 Subject: [redhat-lspp] Re: kickstart changes to select capp or lspp configuration In-Reply-To: <45CA41A8.3060100@hp.com> References: <45C28222.1010606@hp.com> <20070207061902.GA5396@w-m-p.com> <45CA41A8.3060100@hp.com> Message-ID: <20070207214136.GD5396@w-m-p.com> On Wed, Feb 07, 2007 at 04:16:24PM -0500, Linda Knippers wrote: > Klaus Weidner wrote: > > I'll use "--tries=2" this time, is that better? Or is it calling busybox > > "wget" for some reason which doesn't have that option? (It shouldn't, > > it's chrooted to the installed system.) What's the error output? > > I don't recall seeing an error but I don't the output anymore. I'm pretty > sure it was calling the right wget. Without the retries option I get a > message that tells me that it was try number 2 that worked. > > HTTP request sent, awaiting response... 200 OK > Length: 36763 (36K) [application/x-rpm] > --14:49:01-- (try: 2) > ... > > I don't know what's happening on the first try. With your 0.18 script I > could never wget the certification rpm without escaping to the shell and > manually running wget. > > How long does 20 retries take? If it's DNS failure or timeouts due to misrouted packets, probably close to 20 minutes :-( Ok, how about 3 tries to leave a spare for cases such as yours? I'd like to know why Ctrl-C kills the entire session and not just wget and if that's fixable, but I don't have a good idea how to debug that. -Klaus From klausk at br.ibm.com Wed Feb 7 23:37:33 2007 From: klausk at br.ibm.com (Klaus Heinrich Kiwi) Date: Wed, 07 Feb 2007 21:37:33 -0200 Subject: [redhat-lspp] audit records when specifying an invalid context at ssh login Message-ID: <200702072336.l17Na6R7019519@d24av01.br.ibm.com> Ok, when I try to login as testuser/sysadm_r at host, but testuser isn't allowed as sysam_r, I get: type=USER_AUTH msg=audit(1170871741.978:4373): user pid=18653 uid=0 auid=4294967295 subj=system_u:system_r:sshd_t:s0-s15:c0.c1023 msg='PAM: authentication acct=testuser : exe="/usr/sbin/sshd" (hostname=alex.ltc.br.ibm.com, addr=127.0.0.1, terminal=ssh res=success)' type=USER_ACCT msg=audit(1170871741.982:4374): user pid=18653 uid=0 auid=4294967295 subj=system_u:system_r:sshd_t:s0-s15:c0.c1023 msg='PAM: accounting acct=testuser : exe="/usr/sbin/sshd" (hostname=alex.ltc.br.ibm.com, addr=127.0.0.1, terminal=ssh res=success)' type=USER_ERR msg=audit(1170871741.992:4375): user pid=18651 uid=0 auid=4294967295 subj=system_u:system_r:sshd_t:s0-s15:c0.c1023 msg='PAM: bad_ident acct=? : exe="/usr/sbin/sshd" (hostname=alex.ltc.br.ibm.com, addr=127.0.0.1, terminal=ssh res=failed)' Note that, from the above, we can't tell that a user was trying to access an invalid context (and what context). Same thing happens when the user successfully logs-in using a non-default role/level - no audit record telling what kind of transition was made. In previous refreshes, we needed to use 'newrole' and both success and failures were audited as 'USER_ROLE_CHANGE' records. I must ask: is this the expected behavior and is this ok with the certification requirements? ?Klaus -- :klaus h kiwi :. From klausk at br.ibm.com Wed Feb 7 22:57:07 2007 From: klausk at br.ibm.com (Klaus Heinrich Kiwi) Date: Wed, 07 Feb 2007 20:57:07 -0200 Subject: [redhat-lspp] audit records when specifying an invalid context at ssh login Message-ID: Ok, when I try to login as testuser/sysadm_r at host, but testuser isn't allowed as sysam_r, I get: type=USER_AUTH msg=audit(1170871741.978:4373): user pid=18653 uid=0 auid=4294967295 subj=system_u:system_r:sshd_t:s0-s15:c0.c1023 msg='PAM: authentication acct=testuser : exe="/usr/sbin/sshd" (hostname=alex.ltc.br.ibm.com, addr=127.0.0.1, terminal=ssh res=success)' type=USER_ACCT msg=audit(1170871741.982:4374): user pid=18653 uid=0 auid=4294967295 subj=system_u:system_r:sshd_t:s0-s15:c0.c1023 msg='PAM: accounting acct=testuser : exe="/usr/sbin/sshd" (hostname=alex.ltc.br.ibm.com, addr=127.0.0.1, terminal=ssh res=success)' type=USER_ERR msg=audit(1170871741.992:4375): user pid=18651 uid=0 auid=4294967295 subj=system_u:system_r:sshd_t:s0-s15:c0.c1023 msg='PAM: bad_ident acct=? : exe="/usr/sbin/sshd" (hostname=alex.ltc.br.ibm.com, addr=127.0.0.1, terminal=ssh res=failed)' Note that, from the above, we can't tell that a user was trying to access an invalid context (and what context). Same thing happens when the user successfully logs-in using a non-default role/level - no audit record telling what kind of transition was made. In previous refreshes, we needed to use 'newrole' and both success and failures were audited as 'USER_ROLE_CHANGE' records. I must ask: is this the expected behavior and is this ok with the certification requirements? Klaus -- .:klaus h kiwi :. From klausk at br.ibm.com Thu Feb 8 00:45:41 2007 From: klausk at br.ibm.com (Klaus Heinrich Kiwi) Date: Wed, 07 Feb 2007 22:45:41 -0200 Subject: [redhat-lspp] sysadm vs. secadm powers Message-ID: <200702080044.l180iEpW000731@d24av01.br.ibm.com> Now that sysadm_r/sysadm_t has supehuman powers, I just wanted to confirm if the following is expected and in conformance with the ToE: role/type | read | write to | run | start/stop | auditd.log | auditd.log | auditctl | auditd sysadm | yes | yes | no | yes secadm | yes | *no* | no | no auditadm | *no* | no | yes | *yes* Thanks, Klaus -- :klaus h kiwi :. From tmraz at redhat.com Thu Feb 8 13:47:46 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 08 Feb 2007 14:47:46 +0100 Subject: [redhat-lspp] audit records when specifying an invalid context at ssh login In-Reply-To: <200702072336.l17Na6R7019519@d24av01.br.ibm.com> References: <200702072336.l17Na6R7019519@d24av01.br.ibm.com> Message-ID: <1170942466.3182.1.camel@perun.kabelta.loc> On Wed, 2007-02-07 at 21:37 -0200, Klaus Heinrich Kiwi wrote: ... > Note that, from the above, we can't tell that a user was trying to access an > invalid context (and what context). Same thing happens when the user > successfully logs-in using a non-default role/level - no audit record > telling what kind of transition was made. > > In previous refreshes, we needed to use 'newrole' and both success and > failures were audited as 'USER_ROLE_CHANGE' records. > > I must ask: is this the expected behavior and is this ok with the > certification requirements? What is your openssh version-release installed? -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From klausk at br.ibm.com Thu Feb 8 16:09:56 2007 From: klausk at br.ibm.com (Klaus Heinrich Kiwi) Date: Thu, 08 Feb 2007 14:09:56 -0200 Subject: [redhat-lspp] Re: audit records when specifying an invalid context at ssh login References: <200702072336.l17Na6R7019519@d24av01.br.ibm.com> <1170942466.3182.1.camel@perun.kabelta.loc> Message-ID: Tomas Mraz wrote: >> I must ask: is this the expected behavior and is this ok with the >> certification requirements? > What is your openssh version-release installed? > [abat at alex ~]$ rpm -qa | grep ssh openssh-clients-4.3p2-16.el5 openssh-4.3p2-16.el5 openssh-server-4.3p2-16.el5 [abat at alex ~]$ -- .:klaus h kiwi :. From tmraz at redhat.com Thu Feb 8 17:37:45 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 08 Feb 2007 18:37:45 +0100 Subject: [redhat-lspp] Re: audit records when specifying an invalid context at ssh login In-Reply-To: References: <200702072336.l17Na6R7019519@d24av01.br.ibm.com> <1170942466.3182.1.camel@perun.kabelta.loc> Message-ID: <1170956265.3182.12.camel@perun.kabelta.loc> On Thu, 2007-02-08 at 14:09 -0200, Klaus Heinrich Kiwi wrote: > Tomas Mraz wrote: > > >> I must ask: is this the expected behavior and is this ok with the > >> certification requirements? > > What is your openssh version-release installed? > > > > [abat at alex ~]$ rpm -qa | grep ssh > openssh-clients-4.3p2-16.el5 > openssh-4.3p2-16.el5 > openssh-server-4.3p2-16.el5 > [abat at alex ~]$ Yes, that's the current one. We actually audit just the case when user requests a level change, not the role change. We also do not audit the case where the requested level is invalid. There is just a message in /var/log/secure for that case. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From casey at schaufler-ca.com Thu Feb 8 18:48:09 2007 From: casey at schaufler-ca.com (Casey Schaufler) Date: Thu, 8 Feb 2007 10:48:09 -0800 (PST) Subject: [redhat-lspp] Re: audit records when specifying an invalid context at ssh login In-Reply-To: <1170956265.3182.12.camel@perun.kabelta.loc> Message-ID: <425353.85704.qm@web36606.mail.mud.yahoo.com> --- Tomas Mraz wrote: > Yes, that's the current one. We actually audit just > the case when user > requests a level change, not the role change. That surprises me. If roles are included in your security claims I would consider changing roles a change in the security state, and hence quite relevant, thus requiring audit. > We also do not audit the > case where the requested level is invalid. You can argue that on the basis of not auditing user errors ... > There is just a message > in /var/log/secure for that case. ... except that by doing that you're saying that it does matter. That's going to make it difficult to explain what your audit policy is. Not impossible, but you don't want to have to explain every decision along these lines. Casey Schaufler casey at schaufler-ca.com From tmraz at redhat.com Thu Feb 8 22:36:12 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 08 Feb 2007 23:36:12 +0100 Subject: [redhat-lspp] Re: audit records when specifying an invalid context at ssh login In-Reply-To: <425353.85704.qm@web36606.mail.mud.yahoo.com> References: <425353.85704.qm@web36606.mail.mud.yahoo.com> Message-ID: <1170974172.3182.30.camel@perun.kabelta.loc> On Thu, 2007-02-08 at 10:48 -0800, Casey Schaufler wrote: > --- Tomas Mraz wrote: > > > > Yes, that's the current one. We actually audit just > > the case when user > > requests a level change, not the role change. > > That surprises me. If roles are included in your > security claims I would consider changing roles > a change in the security state, and hence quite > relevant, thus requiring audit. > > > We also do not audit the > > case where the requested level is invalid. > > You can argue that on the basis of not auditing > user errors ... > > > There is just a message > > in /var/log/secure for that case. > > ... except that by doing that you're saying > that it does matter. That's going to make it > difficult to explain what your audit policy > is. Not impossible, but you don't want to > have to explain every decision along these > lines. Could you please open up a bug report against openssh in RH bugzilla for that? Thank you, -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From linda.knippers at hp.com Fri Feb 9 16:46:33 2007 From: linda.knippers at hp.com (Linda Knippers) Date: Fri, 09 Feb 2007 11:46:33 -0500 Subject: [redhat-lspp] what happens when something can't be audited? Message-ID: <45CCA569.1050809@hp.com> In this bugzilla, Eduardo has accurately described the behavior of cups if auditd is running when cupsd starts up but auditd is stopped afterwards. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227889 He was expecting cupsd to stop printing (not an unreasonable expectation) but it does not. I updated the bugzilla to explain why and to point out that lots of trusted programs issue audit records at the completion of some operation (they include the results in the audit record) and don't undo the operation if issuing the audit record fails. We could certainly change cupsd to fail to queue a job or to cancel a job if it can't be audited but what about the other programs? I know we talked about this alot when the audit failure action routine was added the libaudit but the requirements were never very clear. -- ljk From klaus at atsec.com Fri Feb 9 17:04:09 2007 From: klaus at atsec.com (Klaus Weidner) Date: Fri, 9 Feb 2007 11:04:09 -0600 Subject: [redhat-lspp] what happens when something can't be audited? In-Reply-To: <45CCA569.1050809@hp.com> References: <45CCA569.1050809@hp.com> Message-ID: <20070209170409.GA23502@w-m-p.com> On Fri, Feb 09, 2007 at 11:46:33AM -0500, Linda Knippers wrote: > In this bugzilla, Eduardo has accurately described the behavior of cups if > auditd is running when cupsd starts up but auditd is stopped afterwards. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227889 > > He was expecting cupsd to stop printing (not an unreasonable expectation) > but it does not. > > I updated the bugzilla to explain why and to point out that lots of > trusted programs issue audit records at the completion of some operation > (they include the results in the audit record) and don't undo the operation > if issuing the audit record fails. We could certainly change cupsd to > fail to queue a job or to cancel a job if it can't be audited but what > about the other programs? > > I know we talked about this alot when the audit failure action > routine was added the libaudit but the requirements were never > very clear. The only directly relevant requirement from LSPP is that any actions which would normally be audited must be prevented when the audit trail is full. There is no requirement for preventing actions when the admin has intentionally disabled audit, or if audit is not working for some reason other than a full audit trail. There is a special case for the secure failure mode in pam_loginuid, where login is prevented if auditd is not running. This is done to ensure that the association between user actions and their identity is reliable. -Klaus From Jim at MagitekLtd.com Fri Feb 9 17:33:33 2007 From: Jim at MagitekLtd.com (James W. Hoeft) Date: Fri, 09 Feb 2007 09:33:33 -0800 Subject: [redhat-lspp] what happens when something can't be audited? In-Reply-To: <20070209170409.GA23502@w-m-p.com> References: <45CCA569.1050809@hp.com> <20070209170409.GA23502@w-m-p.com> Message-ID: <45CCB06D.1070006@MagitekLtd.com> While LSPP is the primary concern (considering this is an LSPP list...), from a system perspective there are others. In the case of a system we delivered recently (PL4 - C4I system, so DCID 6/3), the accreditors allowed ten minutes of operation before it had to automatically shut down if audit "failed" (i.e., wasn't running or couldn't write). They wanted it shut down immediately, and it took hours of negotiation to get ten minutes. This was for a "medium availability" system, may have gotten a little more leeway for one at "high", and certainly less for one at "low". This doesn't address the behavior of the individual apps/daemons, but if it isn't TOO much trouble to address an audit "failure" at that level, in order to tailor the behavior based on the criticality of the system, that would be ideal. (in the case of printing, our accreditors would want the job canceled - other functions would be on a case-by-case basis) Jim Klaus Weidner wrote: > On Fri, Feb 09, 2007 at 11:46:33AM -0500, Linda Knippers wrote: >> In this bugzilla, Eduardo has accurately described the behavior of cups if >> auditd is running when cupsd starts up but auditd is stopped afterwards. >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227889 >> >> He was expecting cupsd to stop printing (not an unreasonable expectation) >> but it does not. >> >> I updated the bugzilla to explain why and to point out that lots of >> trusted programs issue audit records at the completion of some operation >> (they include the results in the audit record) and don't undo the operation >> if issuing the audit record fails. We could certainly change cupsd to >> fail to queue a job or to cancel a job if it can't be audited but what >> about the other programs? >> >> I know we talked about this alot when the audit failure action >> routine was added the libaudit but the requirements were never >> very clear. > > The only directly relevant requirement from LSPP is that any actions > which would normally be audited must be prevented when the audit trail is > full. There is no requirement for preventing actions when the admin has > intentionally disabled audit, or if audit is not working for some reason > other than a full audit trail. > > There is a special case for the secure failure mode in pam_loginuid, > where login is prevented if auditd is not running. This is done to ensure > that the association between user actions and their identity is reliable. > > -Klaus > > -- > redhat-lspp mailing list > redhat-lspp at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-lspp > > > From casey at schaufler-ca.com Fri Feb 9 17:35:37 2007 From: casey at schaufler-ca.com (Casey Schaufler) Date: Fri, 9 Feb 2007 09:35:37 -0800 (PST) Subject: [redhat-lspp] what happens when something can't be audited? In-Reply-To: <20070209170409.GA23502@w-m-p.com> Message-ID: <20070209173537.32165.qmail@web36608.mail.mud.yahoo.com> --- Klaus Weidner wrote: > On Fri, Feb 09, 2007 at 11:46:33AM -0500, Linda > Knippers wrote: > > In this bugzilla, Eduardo has accurately described > the behavior of cups if > > auditd is running when cupsd starts up but auditd > is stopped afterwards. > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227889 > > > > He was expecting cupsd to stop printing (not an > unreasonable expectation) > > but it does not. > > > > I updated the bugzilla to explain why and to point > out that lots of > > trusted programs issue audit records at the > completion of some operation > > (they include the results in the audit record) and > don't undo the operation > > if issuing the audit record fails. We could > certainly change cupsd to > > fail to queue a job or to cancel a job if it can't > be audited but what > > about the other programs? > > > > I know we talked about this alot when the audit > failure action > > routine was added the libaudit but the > requirements were never > > very clear. > > The only directly relevant requirement from LSPP is > that any actions > which would normally be audited must be prevented > when the audit trail is full. To the best of my knowledge no one has ever tried an approach other than "halt the system" under the full audit files scenario. You can't know if some operations will require audit in advance, and auditable operations typically cannot be undone. Having auditable operations fail because there's no space would cause more damage than a tornado in a trailer park if you could make it work. Making them hang until space is available has been tried, and it introduces all sorts of races, retries, communication failures, and frustrations. It makes no sense to have cups (or any individual component) undo operations if audit fails unless all components do so. I am skeptical that sufficient coverage is possible to meet the LSPP requirement using any technique short of "halt". > There is no requirement for preventing actions > when the admin has > intentionally disabled audit, or if audit is not > working for some reason > other than a full audit trail. Casey Schaufler casey at schaufler-ca.com From linda.knippers at hp.com Fri Feb 9 17:18:52 2007 From: linda.knippers at hp.com (Linda Knippers) Date: Fri, 09 Feb 2007 12:18:52 -0500 Subject: [redhat-lspp] what happens when something can't be audited? In-Reply-To: <20070209170409.GA23502@w-m-p.com> References: <45CCA569.1050809@hp.com> <20070209170409.GA23502@w-m-p.com> Message-ID: <45CCACFC.3090004@hp.com> Klaus Weidner wrote: > On Fri, Feb 09, 2007 at 11:46:33AM -0500, Linda Knippers wrote: > >>In this bugzilla, Eduardo has accurately described the behavior of cups if >>auditd is running when cupsd starts up but auditd is stopped afterwards. >>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227889 >> >>He was expecting cupsd to stop printing (not an unreasonable expectation) >>but it does not. >> >>I updated the bugzilla to explain why and to point out that lots of >>trusted programs issue audit records at the completion of some operation >>(they include the results in the audit record) and don't undo the operation >>if issuing the audit record fails. We could certainly change cupsd to >>fail to queue a job or to cancel a job if it can't be audited but what >>about the other programs? >> >>I know we talked about this alot when the audit failure action >>routine was added the libaudit but the requirements were never >>very clear. > > > The only directly relevant requirement from LSPP is that any actions > which would normally be audited must be prevented when the audit trail is > full. Ok, so same requirement as for CAPP. > There is no requirement for preventing actions when the admin has > intentionally disabled audit, or if audit is not working for some reason > other than a full audit trail. And in the log or disk full case, we take the action before the disk is actually full so we shouldn't be losing anything. I think we can close this bz as not a bug. Thanks. > There is a special case for the secure failure mode in pam_loginuid, > where login is prevented if auditd is not running. This is done to ensure > that the association between user actions and their identity is reliable. -- ljk From linda.knippers at hp.com Fri Feb 9 21:37:42 2007 From: linda.knippers at hp.com (Linda Knippers) Date: Fri, 09 Feb 2007 16:37:42 -0500 Subject: [redhat-lspp] LSPP kickstart config v0.19 released In-Reply-To: <20070207064905.GB5396@w-m-p.com> References: <20070207064905.GB5396@w-m-p.com> Message-ID: <45CCE9A6.2060002@hp.com> Hi Klaus, > Simplify admin account creation, work around autorelabel $HOME issues I don't think this works. I think the useradd command isn't doing what we expect. With a command like this (taken right out of the ks script): useradd -m -c "ljk2" -G wheel -Z staff_u ljk2 I end up with an ljk2 user that is staff_u:s0 (note s0) in /etc/selinux/mls/seusers. The home directory is labeled: user_u:object_r:user_home_dir_t:SystemLow-SystemHigh If I do a restorecon -v I get this: restorecon reset /home/ljk2 context user_u:object_r:user_home_dir_t:s0-s15:c0.c1023->staff_u:object_r:staff_home_dir_t:s0-s15:c0.c1023 There's a comment in the ks script: # no need to set MLS level, # staff_u defaults to SystemLow-SystemHigh range But that doesn't seem to be the case. If staff_u is supposed to default to SystemLow-SystemHigh then useradd isn't doing the right thing when it creates the selinux user and it doesn't seem to be creating the home directory with the right context. Should I open a new bugzilla or does Dan think we need the semanage and restorecon no matter what? -- ljk From ltcgcw at us.ibm.com Fri Feb 9 22:03:24 2007 From: ltcgcw at us.ibm.com (George C. Wilson) Date: Fri, 9 Feb 2007 16:03:24 -0600 Subject: [redhat-lspp] [Update] LSPP Bug Telecon Mon., Feb. 12 Message-ID: <20070209220324.GA10014@us.ibm.com> The LSPP Development Telecon is now the LSPP Bug Telecon Thanks to all who participated in the LSPP Development Telecon. It has mutated into the LSPP Bug Telecon. We will iterate over a list of bugs affecting features developed for LSPP. IBM continues host the telecon every Monday at 21:00 UTC. 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 after review by the existing participants. 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 casey at schaufler-ca.com Fri Feb 9 22:27:21 2007 From: casey at schaufler-ca.com (Casey Schaufler) Date: Fri, 9 Feb 2007 14:27:21 -0800 (PST) Subject: [redhat-lspp] [Update] LSPP Bug Telecon Mon., Feb. 12 In-Reply-To: <20070209220324.GA10014@us.ibm.com> Message-ID: <20070209222721.83786.qmail@web36604.mail.mud.yahoo.com> --- "George C. Wilson" wrote: > The LSPP Development Telecon is now the LSPP Bug > Telecon Congratulations! That's a major step. Keep up the good work, and start looking for the right place to hang the certificate. Casey Schaufler casey at schaufler-ca.com From klaus at atsec.com Fri Feb 9 22:37:01 2007 From: klaus at atsec.com (Klaus Weidner) Date: Fri, 9 Feb 2007 16:37:01 -0600 Subject: [redhat-lspp] Re: sysadm vs. secadm powers In-Reply-To: <200702080044.l180iEpW000731@d24av01.br.ibm.com> References: <200702080044.l180iEpW000731@d24av01.br.ibm.com> Message-ID: <20070209223701.GB23502@w-m-p.com> On Wed, Feb 07, 2007 at 10:45:41PM -0200, Klaus Heinrich Kiwi wrote: > Now that sysadm_r/sysadm_t has supehuman powers, I just wanted to confirm if > the following is expected and in conformance with the ToE: > > role/type | read | write to | run | start/stop > | auditd.log | auditd.log | auditctl | auditd > sysadm | yes | yes | no | yes > secadm | yes | *no* | no | no > auditadm | *no* | no | yes | *yes* I'd expect auditadm to be able to read and write the audit log, is the current behavior intentional? -Klaus From linda.knippers at hp.com Fri Feb 9 22:53:36 2007 From: linda.knippers at hp.com (Linda Knippers) Date: Fri, 09 Feb 2007 17:53:36 -0500 Subject: [redhat-lspp] Re: sysadm vs. secadm powers In-Reply-To: <20070209223701.GB23502@w-m-p.com> References: <200702080044.l180iEpW000731@d24av01.br.ibm.com> <20070209223701.GB23502@w-m-p.com> Message-ID: <45CCFB70.3080509@hp.com> Klaus Weidner wrote: > On Wed, Feb 07, 2007 at 10:45:41PM -0200, Klaus Heinrich Kiwi wrote: > >>Now that sysadm_r/sysadm_t has supehuman powers, I just wanted to confirm if >>the following is expected and in conformance with the ToE: >> >>role/type | read | write to | run | start/stop >> | auditd.log | auditd.log | auditctl | auditd >>sysadm | yes | yes | no | yes >>secadm | yes | *no* | no | no >>auditadm | *no* | no | yes | *yes* > > > I'd expect auditadm to be able to read and write the audit log, is the > current behavior intentional? I think it was intentional. I think its been that way since the role was created. Folks wanted a role that could manage the audit system but not necessary look at the information, if I recall. -- ljk From sgrubb at redhat.com Sat Feb 10 15:24:34 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Sat, 10 Feb 2007 10:24:34 -0500 Subject: [redhat-lspp] what happens when something can't be audited? In-Reply-To: <45CCA569.1050809@hp.com> References: <45CCA569.1050809@hp.com> Message-ID: <200702101024.34916.sgrubb@redhat.com> On Friday 09 February 2007 11:46, Linda Knippers wrote: > I updated the bugzilla to explain why and to point out that lots of > trusted programs issue audit records at the completion of some operation > (they include the results in the audit record) and don't undo the operation > if issuing the audit record fails. They should all open the audit socket before performing that operation. They could call audit_status and see if the audit daemon is registered. But you would have to have a command line option to tell the program that it should treat the absence of an audit daemon in a way as to deny the requested action. Not all users want this behavior. > We could certainly change cupsd to fail to queue a job or to cancel a job if > it can't be audited but what about the other programs? The should all be fixed to do that I suppose. I can add a function to libaudit that does the status check and returns yes or no if the audit daemon is registered. Would this help? -Steve From sgrubb at redhat.com Sat Feb 10 15:32:57 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Sat, 10 Feb 2007 10:32:57 -0500 Subject: [redhat-lspp] what happens when something can't be audited? In-Reply-To: <45CCB06D.1070006@MagitekLtd.com> References: <45CCA569.1050809@hp.com> <20070209170409.GA23502@w-m-p.com> <45CCB06D.1070006@MagitekLtd.com> Message-ID: <200702101032.58081.sgrubb@redhat.com> On Friday 09 February 2007 12:33, James W. Hoeft wrote: > This doesn't address the behavior of the individual apps/daemons, but if > it isn't TOO much trouble to address an audit "failure" at that level, > in order to tailor the behavior based on the criticality of the system, > that would be ideal. It doesn't sound like too much trouble for some operations. > (in the case of printing, our accreditors would want the job canceled - > other functions would be on a case-by-case basis) I think its reasonable to mark the printer unavailable to keep the job queued or even canceled. -Steve From linda.knippers at hp.com Sat Feb 10 19:00:48 2007 From: linda.knippers at hp.com (Linda Knippers) Date: Sat, 10 Feb 2007 14:00:48 -0500 Subject: [redhat-lspp] what happens when something can't be audited? In-Reply-To: <200702101024.34916.sgrubb@redhat.com> References: <45CCA569.1050809@hp.com> <200702101024.34916.sgrubb@redhat.com> Message-ID: <45CE1660.9000902@hp.com> Steve Grubb wrote: > On Friday 09 February 2007 11:46, Linda Knippers wrote: > >>I updated the bugzilla to explain why and to point out that lots of >>trusted programs issue audit records at the completion of some operation >>(they include the results in the audit record) and don't undo the operation >>if issuing the audit record fails. > > > They should all open the audit socket before performing that operation. They > could call audit_status and see if the audit daemon is registered. But you > would have to have a command line option to tell the program that it should > treat the absence of an audit daemon in a way as to deny the requested > action. Not all users want this behavior. Right. That's why we added the audit library routine to get the user selectable failure action from /etc/libaudit.conf. In the cups case, it checks that when it opens the audit socket, which it does when it starts up. When we talked about this before we talked about per-application failure actions but ended up with just a global one. I don't think we want to add command-line options. > >>We could certainly change cupsd to fail to queue a job or to cancel a job if >>it can't be audited but what about the other programs? > > > The should all be fixed to do that I suppose. I can add a function to libaudit > that does the status check and returns yes or no if the audit daemon is > registered. Would this help? I think we've already got what we need in libaudit. The question was about which failures to look for when and what to do about it. According to Klaus we don't have to handle the case where the admin stops the audit daemon, just the log full case, which I believe is handled by the action selected in the auditd config file. -- ljk > > -Steve From sgrubb at redhat.com Sat Feb 10 19:16:52 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Sat, 10 Feb 2007 14:16:52 -0500 Subject: [redhat-lspp] what happens when something can't be audited? In-Reply-To: <45CE1660.9000902@hp.com> References: <45CCA569.1050809@hp.com> <200702101024.34916.sgrubb@redhat.com> <45CE1660.9000902@hp.com> Message-ID: <200702101416.52581.sgrubb@redhat.com> On Saturday 10 February 2007 14:00, Linda Knippers wrote: > That's why we added the audit library routine to get the user selectable > failure action from /etc/libaudit.conf. Did patches get submitted so that trusted programs use it? > In the cups case, it checks that when it opens the audit socket, which it > does when it starts up. When we talked about this before we talked about > per-application failure actions but ended up with just a global one. ?I > don't think we want to add command-line options. I guess you are right. I keep forgetting about that addition. -Steve From linda.knippers at hp.com Sat Feb 10 19:24:50 2007 From: linda.knippers at hp.com (Linda Knippers) Date: Sat, 10 Feb 2007 14:24:50 -0500 Subject: [redhat-lspp] what happens when something can't be audited? In-Reply-To: <200702101416.52581.sgrubb@redhat.com> References: <45CCA569.1050809@hp.com> <200702101024.34916.sgrubb@redhat.com> <45CE1660.9000902@hp.com> <200702101416.52581.sgrubb@redhat.com> Message-ID: <45CE1C02.5090205@hp.com> Steve Grubb wrote: > On Saturday 10 February 2007 14:00, Linda Knippers wrote: > >>That's why we added the audit library routine to get the user selectable >>failure action from /etc/libaudit.conf. > > > Did patches get submitted so that trusted programs use it? Aside from cups, I don't think so. Other programs handle not being able to open the audit socket but they take a hard-coded action rather than a selectable one. - ljk From linda.knippers at hp.com Mon Feb 12 14:55:48 2007 From: linda.knippers at hp.com (Linda Knippers) Date: Mon, 12 Feb 2007 09:55:48 -0500 Subject: [redhat-lspp] newrole doesn't work on serial consoles Message-ID: <45D07FF4.7080304@hp.com> On Friday I filed this bugzilla because at least on my ia64 box, newrole hangs when run on a serial console. Might also hang a regular serial port but I'm not sure. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228102 The short summary is that on my system, newrole is hanging in the open when its trying to relabel the tty. It will also hang when it reopens stdin, stdout and stderr. If I change the opens to have the O_NONBLOCK flag, it works. I don't know if that's the right solution though. I assume what I'm seeing on my serial console has something to do with the way the agetty has configured the port. George, are you seeing the same thing? -- ljk From gcwilson at us.ibm.com Mon Feb 12 15:57:54 2007 From: gcwilson at us.ibm.com (George Wilson) Date: Mon, 12 Feb 2007 09:57:54 -0600 Subject: [redhat-lspp] newrole doesn't work on serial consoles In-Reply-To: <45D07FF4.7080304@hp.com> Message-ID: redhat-lspp-bounces at redhat.com wrote on 02/12/2007 08:55:48: > On Friday I filed this bugzilla because at least on my ia64 box, newrole > hangs when run on a serial console. Might also hang a regular serial > port but I'm not sure. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228102 > > The short summary is that on my system, newrole is hanging in the > open when its > trying to relabel the tty. It will also hang when it reopens stdin,stdout and > stderr. If I change the opens to have the O_NONBLOCK flag, it works. I don't > know if that's the right solution though. I assume what I'm seeing on my > serial console has something to do with the way the agetty has configured the > port. > > George, are you seeing the same thing? I haven't tried a proper serial console in a while. Will definitely give it a shot. It does not hang on the virtual serial console of my ppc64 partition. > > -- ljk > > -- > redhat-lspp mailing list > redhat-lspp at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-lspp Thanks, George Wilson IBM LTC Security Development -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwalsh at redhat.com Mon Feb 12 16:53:49 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 12 Feb 2007 11:53:49 -0500 Subject: [redhat-lspp] LSPP kickstart config v0.18 released In-Reply-To: <45C39296.9060802@hp.com> References: <20070123131425.GE12994@w-m-p.com> <45C39296.9060802@hp.com> Message-ID: <45D09B9D.3040906@redhat.com> Linda Knippers wrote: > Hi Klaus, > > I see that this verison of the ks rpm still has alot of stuff in the > lspp policy module (attached for those not using the rpm). Some of > the policy changes reference bugzillas but not all of them. > > Has Dan pulled these changes into the mls policy? > > -- ljk > > ------------------------------------------------------------------------ > > ## Customized SELinux policy for LSPP evaluated configuration > > policy_module(lspp_policy,1.0) > > ############################################################################# > ### Additional audit > ############################################################################# > > gen_require(` > attribute domain; > ') > > # Audit setting of security relevant process attributes > # These settings are OPTIONAL > auditallow domain self:process setcurrent; > auditallow domain self:process setexec; > auditallow domain self:process setfscreate; > #auditallow domain self:process setsocketcreate; # FIXME > #auditallow domain self:process setipccreate; # FIXME > > This is specific to LSPP so it should be kept. > # bug workaround: vsftpd can't write to tallylog which breaks non-anon login. > # > # Fix proposed to RH 2006-12-18: > # https://enterprise.redhat.com/issue-tracker/?module=issues&action=view&tid=107824 > # https://bugzilla.linux.ibm.com/show_bug.cgi?id=29661 > gen_require(` > type ftpd_t; > ') > auth_rw_faillog(ftpd_t) > auth_append_faillog is the current policy does it need auth_rw_faillog? > # for following, see: > # > # https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=220487 > > ### sshd ################################################## > > gen_require(` > type sshd_t, unlabeled_t, staff_ssh_t, user_ssh_t, port_t; > ') > kernel_tcp_recvfrom_unlabeled(sshd_t) > kernel_tcp_recvfrom_unlabeled(staff_ssh_t) > kernel_tcp_recvfrom_unlabeled(user_ssh_t) > allow staff_ssh_t port_t:tcp_socket name_connect; > allow user_ssh_t port_t:tcp_socket name_connect; > > Not sure how we should handle this. > ### xinetd ################################################ > > gen_require(` > type inetd_t, bin_t, proc_t; > type sshd_exec_t, sshd_t; > ') > > # xinetd needs MLS override privileges to work > mls_fd_use_all_levels(inetd_t) > mls_fd_share_all_levels(inetd_t) > mls_socket_read_to_clearance(inetd_t) > mls_process_set_level(inetd_t) > > These are in the current policy and should be removed. > # miscellaneous xinetd fixes > allow inetd_t self:fd use; > allow inetd_t proc_t:file read; > kernel_read_system_state(inetd_t) > selinux_validate_context(inetd_t) > selinux_compute_create_context(inetd_t) > kernel_tcp_recvfrom_unlabeled(inetd_t) > allow inetd_t self:process { noatsecure rlimitinh setexec siginh transition }; > > These are in the current policy and should be removed. > ### xinetd running sshd ################################### > > # allow xinetd to transition to sshd_t via sshd_exec_t > allow inetd_t bin_t:file { entrypoint execute getattr read }; > allow inetd_t sshd_exec_t:file { entrypoint execute getattr read }; > type_transition inetd_t sshd_exec_t : process sshd_t; > domain_trans(inetd_t, sshd_exec_t, sshd_t) > > # various interactions > allow sshd_t inetd_t:fd use; > allow sshd_t inetd_t:process sigchld; > allow sshd_t inetd_t:tcp_socket { getattr getopt ioctl read setopt write }; > > Should be in current policy. > ------------------------------------------------------------------------ > > -- > redhat-lspp mailing list > redhat-lspp at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-lspp > From dwalsh at redhat.com Mon Feb 12 17:03:11 2007 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 12 Feb 2007 12:03:11 -0500 Subject: [redhat-lspp] Re: sysadm vs. secadm powers In-Reply-To: <45CCFB70.3080509@hp.com> References: <200702080044.l180iEpW000731@d24av01.br.ibm.com> <20070209223701.GB23502@w-m-p.com> <45CCFB70.3080509@hp.com> Message-ID: <45D09DCF.8070601@redhat.com> Linda Knippers wrote: > Klaus Weidner wrote: > >> On Wed, Feb 07, 2007 at 10:45:41PM -0200, Klaus Heinrich Kiwi wrote: >> >> >>> Now that sysadm_r/sysadm_t has supehuman powers, I just wanted to confirm if >>> the following is expected and in conformance with the ToE: >>> >>> role/type | read | write to | run | start/stop >>> | auditd.log | auditd.log | auditctl | auditd >>> sysadm | yes | yes | no | yes >>> secadm | yes | *no* | no | no >>> auditadm | *no* | no | yes | *yes* >>> >> Auditadm can read the auditd.log and write it but needs to be logged in at SystemHigh to be able to do it. >> I'd expect auditadm to be able to read and write the audit log, is the >> current behavior intentional? >> > > I think it was intentional. I think its been that way since the role was > created. Folks wanted a role that could manage the audit system but > not necessary look at the information, if I recall. > > -- ljk > > -- > redhat-lspp mailing list > redhat-lspp at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-lspp > From klausk at br.ibm.com Mon Feb 12 20:57:32 2007 From: klausk at br.ibm.com (Klaus Heinrich Kiwi) Date: Mon, 12 Feb 2007 18:57:32 -0200 Subject: [redhat-lspp] Re: Re: sysadm vs. secadm powers References: <200702080044.l180iEpW000731@d24av01.br.ibm.com> <20070209223701.GB23502@w-m-p.com> <45CCFB70.3080509@hp.com> <45D09DCF.8070601@redhat.com> Message-ID: Daniel J Walsh wrote: > Linda Knippers wrote: >> Klaus Weidner wrote: >> >>> On Wed, Feb 07, 2007 at 10:45:41PM -0200, Klaus Heinrich Kiwi wrote: >>> >>> >>>> Now that sysadm_r/sysadm_t has supehuman powers, I just wanted to >>>> confirm if the following is expected and in conformance with the ToE: >>>> >>>> role/type | read | write to | run | >>>> start/stop >>>> | auditd.log | auditd.log | auditctl | auditd >>>> sysadm | yes | yes | no | yes >>>> secadm | yes | *no* | no | no >>>> auditadm | *no* | no | yes | *yes* >>>> >>> > Auditadm can read the auditd.log and write it but needs to be logged in > at SystemHigh to be able to do it. Please let me know if I'm doing something wrong: -bash-3.1# id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm), (disk),10(wheel) context=staff_u:auditadm_r:auditadm_t:s0-s15:c0.c1023 -bash-3.1# cat /var/log/audit/auditd.log cat: /var/log/audit/auditd.log: Permission denied see that the AVC actually denies the search in the audit directory: type=AVC msg=audit(1171305684.750:3121): avc: ?denied ?{ search } for pid=15869 comm="cat" name="audit" dev=dm-1 ino=93889 scontext=staff_u:auditadm_r:auditadm_t:s0-s15:c0.c1023 tcontext=system_u:object_r:auditd_log_t:s15:c0.c1023 tclass=dir type=SYSCALL msg=audit(1171305684.750:3121): arch=14 syscall=5 success=no exit=-13 a0=fad0fc94 a1=10000 a2=0 a3=1 items=0 ppid=15838 pid=15869 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 comm="cat" exe="/bin/cat" subj=staff_u:auditadm_r:auditadm_t:s0-s15:c0.c1023 key=(null) ?Thanks, ?Klaus -- .:klaus h kiwi :. From thompsmc at us.ibm.com Mon Feb 12 23:02:06 2007 From: thompsmc at us.ibm.com (Michael C Thompson) Date: Mon, 12 Feb 2007 17:02:06 -0600 Subject: [redhat-lspp] Re: Re: sysadm vs. secadm powers In-Reply-To: References: <200702080044.l180iEpW000731@d24av01.br.ibm.com> <20070209223701.GB23502@w-m-p.com> <45CCFB70.3080509@hp.com> <45D09DCF.8070601@redhat.com> Message-ID: <45D0F1EE.5040201@us.ibm.com> Klaus Heinrich Kiwi wrote: > > > Daniel J Walsh wrote: > >> Linda Knippers wrote: >>> Klaus Weidner wrote: >>> >>>> On Wed, Feb 07, 2007 at 10:45:41PM -0200, Klaus Heinrich Kiwi wrote: >>>> >>>> >>>>> Now that sysadm_r/sysadm_t has supehuman powers, I just wanted to >>>>> confirm if the following is expected and in conformance with the ToE: >>>>> >>>>> role/type | read | write to | run | >>>>> start/stop >>>>> | auditd.log | auditd.log | auditctl | auditd >>>>> sysadm | yes | yes | no | yes >>>>> secadm | yes | *no* | no | no >>>>> auditadm | *no* | no | yes | *yes* >>>>> >>>> >> Auditadm can read the auditd.log and write it but needs to be logged in >> at SystemHigh to be able to do it. > Please let me know if I'm doing something wrong: > > -bash-3.1# id > uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm), > (disk),10(wheel) context=staff_u:auditadm_r:auditadm_t:s0-s15:c0.c1023 You need to be SystemHigh-SystemHigh. Mike From latten at austin.ibm.com Mon Feb 12 23:39:57 2007 From: latten at austin.ibm.com (Joy Latten) Date: Mon, 12 Feb 2007 17:39:57 -0600 Subject: [redhat-lspp] Deleting xfrms Message-ID: <1171323597.2603.445.camel@faith.austin.ibm.com> I was looking at a patch D.Miller posted for xfrm_audit_log() and could not help but notice that in pfkey_spddelete() and xfrm_get_policy() we delete policy first and then check to see if we have permissions to. Am I missing the original intentions or is this incorrect? Shouldn't it be check the permissions first and then call xfrm_policy_bysel_ctx()? pfkey_spddelete() in af_key.c: xp = xfrm_policy_bysel_ctx(XFRM_POLICY_TYPE_MAIN, pol->sadb_x_policy_dir-1, &sel, tmp.security, 1); security_xfrm_policy_free(&tmp); xfrm_audit_log(audit_get_loginuid(current->audit_context), 0, AUDIT_MAC_IPSEC_DELSPD, (xp) ? 1 : 0, xp, NULL); if (xp == NULL) return -ENOENT; err = 0; if ((err = security_xfrm_policy_delete(xp))) goto out; c.seq = hdr->sadb_msg_seq; c.pid = hdr->sadb_msg_pid; c.event = XFRM_MSG_DELPOLICY; km_policy_notify(xp, pol->sadb_x_policy_dir-1, &c); xfrm_get_policy() in xfrm_user.c is very similar. Regards, Joy From loulwas at us.ibm.com Tue Feb 13 00:44:09 2007 From: loulwas at us.ibm.com (Loulwa Salem) Date: Mon, 12 Feb 2007 18:44:09 -0600 Subject: [redhat-lspp] LSPP Development Telecon 02/12/2007 Minutes Message-ID: <45D109D9.1030800@us.ibm.com> 02/12/2007 lspp Meeting Minutes: =============================== Attendees George Wilson (IBM) - GW Lawrence Wilson (IBM) - LW Kris Wilson (IBM) - KEW Loulwa Salem (IBM) - LS Debora Velarde (IBM) - DV Michael Thompson (IBM) - MT Joy Latten (IBM) - JL Kylene J Hall (IBM) - KH Irina Boverman (Red Hat) - IB Steve Grubb (Red Hat) - SG Dan Walsh (Red Hat) - DW Eric Paris (Red Hat) - EP Tomas Mraz (Red Hat) Lisa Smith (HP) - LMS Linda Knippers (HP) - LK Matt Anderson (HP) - MA Klaus Weidner (Atsec) - KW Chad Hanson (TCS) - CH Tentative Agenda: GW: Irena sent a list of bugs. We'll use tracking bug 224041 that Irena opened for us. If everyone can get that bug opened so we can all be on the same page. We'll go directly off of Irena's tracker bug. Once on the bug, if you expand dependency tree you get the nice list we'll go over. SG: there is one thing I wanted to do, as we go through the list, we can add a name to who is working on it. All that you have is the RedHat maintainer, who may not be the person working on it GW: makes sense .. absolutely. Who wants to do the updating IB: I can update the bugzilla. just put info in meeting note and publish it as well RHEL 5+ Packages: kernel-2.6.18-6.el5.lspp.64 kernel-devel-2.6.18-6.el5.lspp.64 kernel-doc-2.6.18-6.el5.lspp.64 mcstrans-0.2.1-1.el5 selinux-policy-2.4.6-32.el5 selinux-policy-devel-2.4.6-32.el5 selinux-policy-mls-2.4.6-32.el5 selinux-policy-strict-2.4.6-32.el5 selinux-policy-targeted-2.4.6-32.el5 Bug List Provided by Irina Boverman Fri Feb 9 13:58:56 EST 2007: ID Alias Sev Pri Plt Status Resolution Summary 211827 nor nor All ASSI LSPP: Can't mount with additional contexts GW: this one has been reopened by klaus kiwi in Brazil. LK: looks like Dan updated it today as being fixed DW: mcstrans is still a bit broken. The problem is we don't really have good syntax for it. I sent out an email suggesting what I would like to see done with it. LK: does this bugzilla need another update saying it is not fixed then? DW: we fixed the ssh, the problem now is that the translation is still not working. translating multiple categories is a bit difficult. I am trying to figure out the best way to code it up. SG: Are you saying this bug is mcstrans and not util-Linux related? DW: correct. There is bug in setrans that was truncating labels CH: it's entirely a translation problem DW: it's truncating everything after first comma. the ssh problem and mount problem are really same thing. SG: we should close one as a duplicate of other DW: should really close both and open new bug on translation. these two bugs are just reporting a symptom of bad translation. The real problem is the translation mechanism. I think the way I understand it it's difficult because of all rules we have SG: are we gonna close these two and open new one then? DW: mcstrans is just broken GW: so we need to design new syntax DW: if you had left hand side translated, then you return left hand side. The curent code looks for sensitivty then tries to translate entire left side. if you have a range, it translates right and left sides separately. we are trying to optimize it to use least ammount of characters and be easy on people filling up the table. I think this is better discussed on the list. I will try to write syntax then write code to match that syntax. I don't want to have to specially code systemHigh. GW: Ok, so we need to hammer details on list. this will affect selinux as well as lspp? DW: On selinux side we ignore sensitivty so it's not a problem .. that's why it wasn't caught before. GW: ok, sounds like we need to take this off line IB: libselinux it's not on the list ... GW: these 2 bugs will get closed and new one will open and we'll continue discussion on mailing list. LS: who's going to take action on this bug? GW: Dan volunettered to close other two and open a new one 218386 nor nor pow ASSI LSPP: labeled ipsec does not work over loopback JL: I didnt' have time last week to check this. I'll try this week. GW: do you mind your name being assigned to it JL: not really, but I don't know who else will work on it. I know the issue, I just need to go see if it is someting we can resolve. GW: 219611 is currently closed. why is it still on the list IB: I'll remove them, sometime is shows up if discussion is still going SG: I'd consider those closed.. if there is still discussion it should be re-opened. Modified means it has been fixed and still waiting QA review. 220482 nor nor All ASSI LSPP: CIPSO-to-unlabeled TCP connections block LS: Paul had put a comment in the bugzilla and I tried his suggestion (to try the connection in the other direction). From what I can see which I also posted in the bug, the communication doesn't happen as long as one system doens't understand cipso and the other does. What seems to be happening is that the none cipso system doesn't understand the cipso option it's receiving and drops the packet sending and ICMP error ack to the cipso system. I thought that was the expected behavior and Paul confirmed that. Now I am just waiting for Klaus to say if that is satisfactory. KW: I think it's been two separate issues, first there was specific bug for kernel not allocating enough memory for the header. This is now a separate issue but I am not sure what the problem is. For evaluation puprose, it is ok if two (cipso/non-cipso) systems don't talk to each other SG: what about ability to export data requirement? KW: The cipso configured system can reject unlabeled packets which we have. From evaluation point of view I don't have an opinion on that GW: if it meets the requirement is this going to be acceptable to everyone? IB: if it's not a bug it should be changed back to modified. LK: well, the original problem was fixed .. GW: so is this ok. it's really a RH call SG: seems people would want the ability to export to unlabeled medium if they want to. KW: this problem is only if you have netlabel on. LS: Right, the problem is that the other non-cipso system just doesn't know what to do. On the rhel cipso system, you can set it to accept or deny unlabed packets, so we do have that option available. KW: it seems to be that the cipso configured system is behaving as expected GW: what does the unlabeled toggle do then? KW: tells the rhel5 system to reject the packet if it is unlabeled. but there is nothing we can change to make the non-cipso system understand cipso. SG: seems that it should be bi-directional to not send labeled packets ... LS: if you want it to send unlabled packets out you just disable the netlabel cipso configurations. KW: I'm not up to date on iptables, but could you also set iptables to configure it that way, to send unlabeld packets to certain hosts that don't understand cipso. LK: I think we should post something so paul can see it and respond GW: right .. so are we comfortable closing this out. LK: I think it is working as expected, or as paul intended it for it. KW: I was just looking and there is an iptables option to configure rhel5 system to stip label based on which IP you are sending to GW: good so it sounds there is no issue. this one should be closed. SG: who ever is testing this bug should close it LS: I can close it and explain we discussed it on this call 223532 nor nor All ASSI [LSPP] crontab manpages reference older environment variable IB: naturally .. SG: this should be in modified state as well 223840 hig nor All NEW [LSPP] getfacl fails to correctly display all information... KW: this is actually a very old one. this is not a problem that needs fixing for evaluation. The getfacl tool is buggy, but the important thing is that the underlying syscalls are working. just tool is buggy. SG: we want to fix this once and for all even if it's not required, so it doesn't come up again. KW: I posted a proposed fix for upstream and they did something else which didn't fix it. there are other related bugs in there as well as reference. SG: I think the maintainer needs advice on this one. This bug should really be in "need info" state because the maintainer doesn't know what to do with it KW: people need to agree on what behavior they want. The behavior should be consistant at least. SG: can you update the bugzilla for our maintainer please with your input KW: ok SG: I think he'll fix it if he knows what we want ... KW: I would like the original fix I posted. I don't know if other people would like that. IB: so does this mean we need discusion for that? SG: klaus will update the bugzilla KW: I'll add info, but I don't care much since this is not evaluation relevant SG: great. I'd like to get this done so we don't get back to it 223864 nor nor All NEW LSPP: Exceptions to expected audit behavior should be doc... SG: I'm still thinking about that one, and where to put it. GW: rhel5 docs is done, so this would have to go in guidance or errata or something.. maybe man pages SG: if we put it in man pages then every kernel that goes out I gotta check to see if it changed. seems to me it might be part of audit docs in kernel package. KW: for purpose of evaluation, it would be put in evaluated configuration guide where all docs that didn't make it in are EP: aren't these glibc oditties? LK: glibc oddity was documented in library manpage GW: weren't there 2 of them I think LK: yes, I think they went in different places also, there was the off by 1 and by 100 hex KH: the off by 100 hex is in man page GW: so we want to documents this as an exception in guidance and RH can choose to pick up later SG: it may need to go in glibc. I need to go check on it EP: I think James Antill is the one that first looked at this. 223894 nor nor All ASSI [LSPP] crontab doesn't report an error when a job is to b... DW: I put a patch out for that to the cron maintaner. EP: I thought you also posted an updated version. GW: so that's another pacakage we need to carry. DW: I'll have to check and see if I built it. SG: it's in rawhide DW: I need to build a rhel version GW: another package I forgot to mention is the audit package. we need that still Steve, right? SG: yes GW: ok, I'll add those to my list. 223918 nor nor All ASSI LSPP: audit logs bogus obj label in some PATH records LK: Amy she submitted patches for some of these SG: she retracted them all. We were talking to Al before he sent them to Linus, and she said she wants to rework them all. LK: she filed 2 more today so I think she plans to get these out tonight or tomorrow, since she'll be on vacation after tomorrow. SG: we'll put Amy's name next to these audit bugs LK: bug 228386 is the ptrace one. I think it's ok to have her name by others, but not that one, she is not currently working on it. I think it'll be good if someone else takes look at it. there was a question about if audit hooks can be put in place of lsm hooks. SG: yes, there was discussion on audit list about that LK: I suggested we start by asking selinux guys about selinux hooks, but I don't think there was anything done since then, maybe we can get Al to look at it SG: I'll see if I can get Al to help. so we'll assign the audit bugs to Amy 223919 nor nor All ASSI LSPP: audit does not log obj label when opening an existi... LK/SG: assigned to amy 224080 nor nor All NEW LSPP: audit does not log obj label for mq_timedreceive/mq... LK/SG: assigned to Amy 224637 nor nor All ASSI LSPP: Problem SSH-ing into LSPP system with multiple cate... KH: we are still working on this one actively SG: I think that is the same one that Dan was talking about with translation strings .. KH: is there reason we see very different behavior on Zseries KW: comma vs. period thing you mean? KH: on Zseries, we don't even see the categories KW: that sounds more serious SG: sounds like another bug KW: is there a test for mcstrans DW: I can work on that KW: can you make it public, so we can use it as well. KH: this bug keeps coming back as fixed and I keep seeing it again KW: the low level functionality seems to be broken. so maybe have some testing for mcstrans. I think there is little confidence at this point that mcstrans works correctly. GW: we had another person confirm the fix and that might have added to the confusion KH: seems to have been fixed on all platforms but Z SG: if the problem is mutated, we should have another bug I think LK: sounds like we shouldn't try to re-test until there is new mcstrans IB: so this will be closed and some one will open a new bug GW: kylie can you open a new bug KH: yes GW: thank you. 225328 nor nor All ASSI LSPP: ipsec drops first packet when using IKE daemon SG: that one I need to get in lspp kernel. I think patch was accepted. JL: steve I was gonna ask for your help on that. I took latest kernel and patched it with the patch form David Miller, I couldn't get it to work with labeled ipsec first, it just hangs; when I run regular ipsec, it work. when I was working with it, it seemed fine, but I ran a stress test, minutes into stress test, I get a kernel crash .. I think it's crashing in ipsec audit code. it's audit_log_task_context, I am not really familiar with that code, so I was gonna ask for your help. I wanted to make sure it's not David's patch (btw .. I am using upstream kernel), so I just ran Linux-2.6.20 and still got a crash. I'm not sure if it's ipsec auditing or because of the call ipsec is making to the audit code. CH: did you have two problems. labeled ipsec wasn't working correctly then a crash? JL: I couldn't even do labeled ipsec and I got a kernel crash. Before I can proceed, I need to fix this. SG: so you got oops for that JL: yeah, I'll send it to you SG: cause I am looking at that code now and I don't see it referencing any memory it gets. JL: me too, I'm clueless at this point. I'll send the oops to you and point me in right direction. SG: maybe the current... JL: part of stack trace was kmalloc and I was wondering about that.. it crashes on both kernels too.. SG: send me the oops and I think we can take over from here CH: if you have problem with labeled stuff, venkat can help with that as well JL: great, thank you both. SG: just append it to the bugzilla so everyone can do that JL: even if it's an upstream kernel EP: yes, just put it there so we can know what's going on. SG: we should have separate bugzilla for this also JL: Eric, you sent me an email about another oops and David Miller is looking at it. He doesn't like the ipsec audit code. I'll take his patch and test it. should I open bugzilla for that on lspp kernel EP: yes, might as well .. JL: as soon as I get those things done, I'll go back to testing David's patch. See why it didn't work for labeled ipsec; I am not sure what's going on since his fix seems to be transparent regarding labeled or unlabeled. 225355 nor nor All CLOS DUPL LSPP: Label translation not reversible, causing ssh login... 225443 nor nor ppc NEW LSPP: No console login on first boot GW: This looks like it was fixed thanks to Linda's work. LK: I haven't tested the updated policy DW: I might have missed some stuff, so try it and let me know please.. 226780 nor nor All ASSI LSPP: audit of writes to files of bin_t produces no records SG: I need to build an audit package and get that for people to try. 227412 nor nor All NEW lspp: /root context isn't right on install GW: we talked about it a bit last week KW: should be fixed in latest kickstart but there were other issues, so I need to make another drop. The workaround is manually relabeling those directories LK: klaus, did you see my mail regarding users being set at wrong level. KW: yes, I saw that, I thought I tested that explicitly, but might have tested the wrong thing. I'll look into it and fix that. IB: so is there a workaround for this bug? LK: we'll have fix in kickstart script. KW: you can mark it "no fix" if you want it out of the bug list IB: someone needs to mark it "no fix" SG: I'll take care of it 227733 nor nor All ASSI [LSPP] unable to ssh into a system as root/auditadm_r 227889 hig nor All ASSI [LSPP] CUPS is printing with Audit daemon stopped GW: once I get self tests done, won't this help a bit KW: I don't think it is a requirement to meet lspp. if admin stopped audit, there is no specific requirement for action to be taken GW: I think the issue was explaining it to a creditor KW: it would be nice to have function to get status of audit as a library .. SG: it asks that given that failure, what should I do? it would be easy to make it a library function LK: to me the real issue is that most things are audited after the fact, so you can't prevent it, whats the use? SG: do audit netlink open, see if audit is running LK: that's what cups does, but things can happen between when you open netlink and when audit is written SG: right, but we narrow down the window as a try. MA: I think it's a case that would happen when using useradd SG: changing hardware clock GW: do we need to do anything about it SG: klaus said from evaluation point of view it meet requirements. KW: if it causes problems when people try to deploy system, that's something I don't know about GW: Casey brought that up .. right? LK: if audit can't audit, we halt the system KW: the self test tool panics systems if it's not in a sane state GW: I think that is what we wanted to do CH: I think we can use the tools to just start it.. tends to make them happy SG: yeah, we can do that GW: what if it's in a bad state, do we try so many times for example SG: if you try to restart audit and there is a problem it'll tell you and you can check the return GW: is it sufficient to just check auditd status or should a dummy log be logged as well SG: I think checking the status is probably good enough, since your test script will run periodically GW: you can have watcher process on audit SG: there are people asking about running it out of inittab, it was never designed to do that. I'm thinking this over to decide if I should do that. IB: so what to do with this bug? SG: I think we can close this as not a bug. this kinda comes back to a more general issue, we got those library functions added in, and it was added to cups but wasn't used into anything else IB: George it was opened by IBM, so should be closed by IBM GW: ok, fluery opened this, I'll take care of it. GW: looks like dan already fixed 228102. LK: I'm guessing this is an issue with how egetty configures the device. I verified the behavior on that. George in your case, what do you have agetty or mingetty? GW: I think it is agetty LK: if mingetty it can be an ia64 problem. GW: this is an agetty .. maybe you should try that ... I have not tried a serial console in a while CH: we use agetty also, but I didn't think we had issues, we use in in non enforcing maybe LK: this is not related to enforcing or not.. GW: I just tried it on a virtual console but I'll try on real console .. we can verify.. I'll post to the bug whatever result I get. 228107 labels for labeled printing don't wrap MA: there are other internal buffers that can't handle those longer labels, I'm going and finding those, once I have all tracked down and fixed, it should be done. I think we'll need to carry a cups as well. LK: this is something required for evaluation .. right? MA: if labels don't wrap, you can loose info about labels, since it can spill off the end of the page. I couldn't figure out why it was having problems, it turned out there was lots of 1024 char buffers that I was passing larger info into. GW: Ok, miscellaneous issues, I have not done anything on self tests, I am hoping I can do something this week. I may have a trip out of town for the next few days. If I make that trip I should work on it over the weekend. I am still committed to doing that. Other misc issues? MT: the issues klaus kiwi had .. GW: oh, right .. there were couple of issues, one was chcon issue (chcon file at systemlow to s15, and got denied) MT: what level was he in? non sysadm can't reclassify info. it's in the constraints. you need specific privileges to change mls sensitivity of file. GW: so not strictly BLP but desirable behavior non the less MT: because we have the write-equal constraint, we can't do that. GW: everybody agrees this is desirable. Another issue was being able to print to files not to network devices. klaus kiwi sent me this ... unable to print to file using cups...do we need to support printing to a file KW: this is using cups to print to file, usually when users are printing to file, they use application option and not related to cups. I think it is ok to add an allow rule for that. DW: did they use spool_t MA: I think the other problem is that the check is only checking if actually allowed to write to char device. allow rule should be $1_lpr_t to allow for it to do that DW: we're looking for file type, not char file type MA: at this time, it's hard coded to be char file. from cups perspective printing to file is not important DW: what do you mean? MA: that has to check the user context and compare it to output device context. KW: what do you mean it assumes it. doesn't cups reject attempts if it is not char device MA: if avc check fails then cups rejects the job KW: if there is sufficient policy in place, would it permit printing? MA: yes .. DW: I can make policy to make cups do that, the check is a matter of getting policy correct MA: check as it is currently is hard coded with char file. cupsd should be able to write to file even though it's a regular file MT: does it have policy permissions to do that? DW: I think I need to look at code, I am not following you MA: avc-has-perm is using setclass file with char device to setup it's query LK: maybe let people know that cups does its avc calls itself DW: the way to get around it in policy is to say user has permissions to use char file MA: in klaus kiwi's setup it seems he will already have output file created except for the right context.. DW: should we fix .. MA: there is more than just that to be changed to support printing to a regular file MT: do we really need this functionality MA: I thought we weren't going to do it MT: as this is not really impacting anything KW: I think this was to test it without having physical printer around, and having policy to allow that would be fine MT: so we should a hack policy .. KW: what you hack up should be shown that it doesn't break system security and doesn't make results not applicable. GW: anything else that anyone needs to bring up. ok, I'll get something done on self test and we'll keep working on resolving remaining issues. Thanks everyone. From klaus at atsec.com Tue Feb 13 04:49:42 2007 From: klaus at atsec.com (Klaus Weidner) Date: Mon, 12 Feb 2007 22:49:42 -0600 Subject: [redhat-lspp] LSPP kickstart config v0.18 released In-Reply-To: <45D09B9D.3040906@redhat.com> References: <20070123131425.GE12994@w-m-p.com> <45C39296.9060802@hp.com> <45D09B9D.3040906@redhat.com> Message-ID: <20070213044942.GA9821@w-m-p.com> On Mon, Feb 12, 2007 at 11:53:49AM -0500, Daniel J Walsh wrote: > Linda Knippers wrote: > >I see that this verison of the ks rpm still has alot of stuff in the > >lspp policy module (attached for those not using the rpm). Some of > >the policy changes reference bugzillas but not all of them. > > > >Has Dan pulled these changes into the mls policy? Dan, thanks for reviewing them. I'll delete the obsolete parts, more below about the changes that are still needed. > ># Fix proposed to RH 2006-12-18: > ># > >https://enterprise.redhat.com/issue-tracker/?module=issues&action=view&tid=107824 > ># https://bugzilla.linux.ibm.com/show_bug.cgi?id=29661 > >gen_require(` > > type ftpd_t; > >') > >auth_rw_faillog(ftpd_t) > > > auth_append_faillog is the current policy does it need auth_rw_faillog? I tried without the additional rule and it didn't work. If I understand the mechanism correctly, the /var/log/tallylog file is accessed by seeking to a position based on the numerical UID, so it needs full read/write access. I updated one of the bugs where this was discussed, but could not reopen it due to lack of permissions. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=220085 > ># https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=220487 > > > >### sshd ################################################## > > > >gen_require(` > > type sshd_t, unlabeled_t, staff_ssh_t, user_ssh_t, port_t; > >') > >kernel_tcp_recvfrom_unlabeled(sshd_t) > >kernel_tcp_recvfrom_unlabeled(staff_ssh_t) > >kernel_tcp_recvfrom_unlabeled(user_ssh_t) > >allow staff_ssh_t port_t:tcp_socket name_connect; > >allow user_ssh_t port_t:tcp_socket name_connect; > > > > > Not sure how we should handle this. This isn't needed anymore with current policy. I'm adding the following to the config script to assign ssh_port_t to port 222: semanage port -a -t ssh_port_t -p tcp 222 -Klaus From klaus at atsec.com Tue Feb 13 04:56:05 2007 From: klaus at atsec.com (Klaus Weidner) Date: Mon, 12 Feb 2007 22:56:05 -0600 Subject: [redhat-lspp] LSPP kickstart config v0.19 released In-Reply-To: <45CCE9A6.2060002@hp.com> References: <20070207064905.GB5396@w-m-p.com> <45CCE9A6.2060002@hp.com> Message-ID: <20070213045605.GB9821@w-m-p.com> On Fri, Feb 09, 2007 at 04:37:42PM -0500, Linda Knippers wrote: > Hi Klaus, > > > Simplify admin account creation, work around autorelabel $HOME issues > > I don't think this works. I think the useradd command isn't doing what > we expect. With a command like this (taken right out of the ks script): > useradd -m -c "ljk2" -G wheel -Z staff_u ljk2 > I end up with an ljk2 user that is staff_u:s0 (note s0) in > /etc/selinux/mls/seusers. > > The home directory is labeled: > user_u:object_r:user_home_dir_t:SystemLow-SystemHigh > > If I do a restorecon -v I get this: > restorecon reset /home/ljk2 context > user_u:object_r:user_home_dir_t:s0-s15:c0.c1023->staff_u:object_r:staff_home_dir_t:s0-s15:c0.c1023 > > There's a comment in the ks script: > # no need to set MLS level, > # staff_u defaults to SystemLow-SystemHigh range > But that doesn't seem to be the case. > > If staff_u is supposed to default to SystemLow-SystemHigh then useradd isn't > doing the right thing when it creates the selinux user and it doesn't seem to > be creating the home directory with the right context. > > Should I open a new bugzilla or does Dan think we need the semanage and > restorecon no matter what? I'm adding the semanage and restorecon again. If they are redundant due to other tool fixes we can always remove them again, but they shouldn't hurt. -Klaus From klaus at atsec.com Tue Feb 13 07:05:28 2007 From: klaus at atsec.com (Klaus Weidner) Date: Tue, 13 Feb 2007 01:05:28 -0600 Subject: [redhat-lspp] LSPP kickstart config v0.20 released Message-ID: <20070213070528.GC9821@w-m-p.com> Hello, a mostly bugfix release. IMPORTANT: the labeled sshd has moved from port 2222 to port 222. The old port was reserved, and it's more secure to use a low port in any case. Use the following to access it: ssh -p 222 user at host The only rule patch left in lspp_policy.te is: auth_rw_faillog(ftpd_t) This is a workaround for the following bug which is marked closed but should IMHO be reopened: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=220085 Known bugs: mcstransd from mcstrans-0.2.2-1.el5.i386.rpm doesn't seem to be translating any labels? Changes (thanks especially to Dan Walsh, Klaus Kiwi, Linda Knippers, Debbie Velarde, and Matt Anderson for their testing and contributions): Add "capp-lspp" service to shut down udevd to ensure it's off in interactive mode config script: add (optional) pretty PS1 prompt containing role/level (thanks Matt) Remove obsolete lspp_policy rules Declare port 222 (used by labeled sshd) to be ssh_port_t type Move labeled sshd to port 222 (was on port 2222) Add "semanage login" and restorecon for admin user creation again. I recommend updating the following packages from http://people.redhat.com/dwalsh/SELinux/RHEL5/ and/or http://people.redhat.com/sgrubb/files/lspp in the postinstall phase: kernel-2.6.18-6.el5.lspp.64.i686.rpm kernel-devel-2.6.18-6.el5.lspp.64.i686.rpm libselinux-1.33.4-4.el5.i386.rpm libselinux-devel-1.33.4-4.el5.i386.rpm libselinux-python-1.33.4-4.el5.i386.rpm mcstrans-0.2.2-1.el5.i386.rpm openssh-4.3p2-17.el5.i386.rpm openssh-clients-4.3p2-17.el5.i386.rpm openssh-server-4.3p2-17.el5.i386.rpm policycoreutils-1.33.12-4.el5.i386.rpm policycoreutils-newrole-1.33.12-4.el5.i386.rpm selinux-policy-2.4.6-37.el5.noarch.rpm selinux-policy-devel-2.4.6-37.el5.noarch.rpm selinux-policy-mls-2.4.6-37.el5.noarch.rpm selinux-policy-strict-2.4.6-37.el5.noarch.rpm selinux-policy-targeted-2.4.6-37.el5.noarch.rpm You'll need to run "rpm -Uvh --oldpackage *.rpm" to install them since the kernel version number looks older than the installed one. You can also do this once the system is installed. The installer should work with the plain RC versions. 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 From sds at tycho.nsa.gov Tue Feb 13 12:39:16 2007 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 13 Feb 2007 07:39:16 -0500 Subject: [redhat-lspp] Re: Deleting xfrms In-Reply-To: <1171323597.2603.445.camel@faith.austin.ibm.com> References: <1171323597.2603.445.camel@faith.austin.ibm.com> Message-ID: <1171370356.3242.24.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2007-02-12 at 17:39 -0600, Joy Latten wrote: > I was looking at a patch D.Miller posted for xfrm_audit_log() > and could not help but notice that in pfkey_spddelete() and > xfrm_get_policy() we delete policy first and then check to see if we > have permissions to. Am I missing the original intentions or > is this incorrect? Shouldn't it be check the permissions first and then > call xfrm_policy_bysel_ctx()? IIUC, the security_xfrm_policy_free call is just freeing the temporary object created from the user context in order to perform the lookup of the xp. The permission check occurs upon security_xfrm_policy_delete, and the actual deletion of the policy occurs upon xfrm_pol_put -> __xfrm_policy_destroy. pfkey_spddelete() does look wrong, since it always calls xfrm_pol_put on the out path, whereas xfrm_get_policy() jumps over the xfrm_pol_put() call upon an error from security_xfrm_policy_delete(). > > pfkey_spddelete() in af_key.c: > > xp = xfrm_policy_bysel_ctx(XFRM_POLICY_TYPE_MAIN, > pol->sadb_x_policy_dir-1, > &sel, tmp.security, 1); > security_xfrm_policy_free(&tmp); > > xfrm_audit_log(audit_get_loginuid(current->audit_context), 0, > AUDIT_MAC_IPSEC_DELSPD, (xp) ? 1 : 0, xp, NULL); > > if (xp == NULL) > return -ENOENT; > > err = 0; > > if ((err = security_xfrm_policy_delete(xp))) > goto out; > c.seq = hdr->sadb_msg_seq; > c.pid = hdr->sadb_msg_pid; > c.event = XFRM_MSG_DELPOLICY; > km_policy_notify(xp, pol->sadb_x_policy_dir-1, &c); > > > xfrm_get_policy() in xfrm_user.c is very similar. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Tue Feb 13 12:57:03 2007 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 13 Feb 2007 07:57:03 -0500 Subject: [redhat-lspp] Re: Deleting xfrms In-Reply-To: <1171370356.3242.24.camel@moss-spartans.epoch.ncsc.mil> References: <1171323597.2603.445.camel@faith.austin.ibm.com> <1171370356.3242.24.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1171371423.3242.31.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2007-02-13 at 07:39 -0500, Stephen Smalley wrote: > On Mon, 2007-02-12 at 17:39 -0600, Joy Latten wrote: > > I was looking at a patch D.Miller posted for xfrm_audit_log() > > and could not help but notice that in pfkey_spddelete() and > > xfrm_get_policy() we delete policy first and then check to see if we > > have permissions to. Am I missing the original intentions or > > is this incorrect? Shouldn't it be check the permissions first and then > > call xfrm_policy_bysel_ctx()? > > IIUC, the security_xfrm_policy_free call is just freeing the temporary > object created from the user context in order to perform the lookup of > the xp. The permission check occurs upon security_xfrm_policy_delete, > and the actual deletion of the policy occurs upon xfrm_pol_put -> > __xfrm_policy_destroy. pfkey_spddelete() does look wrong, since it > always calls xfrm_pol_put on the out path, whereas xfrm_get_policy() > jumps over the xfrm_pol_put() call upon an error from > security_xfrm_policy_delete(). Ah, sorry - I see what you mean now. xfrm_policy_bysel_ctx() does appear to unlink the policy and kill it, so it looks like you are correct - the security_xfrm_policy_delete() hook is being called too late. -- Stephen Smalley National Security Agency From latten at austin.ibm.com Wed Feb 14 23:26:41 2007 From: latten at austin.ibm.com (Joy Latten) Date: Wed, 14 Feb 2007 17:26:41 -0600 Subject: [redhat-lspp] ssh/xinetd/getpeercon??? Message-ID: <1171495601.2603.488.camel@faith.austin.ibm.com> I have been playing with the ssh-mls which gets called through xinetd when labeled networking is in use and am confused about what I am seeing. :-) My assumption is that when using this feature, the resulting ssh connection will have single mls level, which is the effective level of the issuer. For example, if I am uid=500(ealuser) gid=500(ealuser) groups=10(wheel),500(ealuser) context=staff_u:staff_r:staff_t:s3-s9 When I issue ssh -p 222 -l , I expect to see "s3" as my new mls level in the new ssh connection when I do an "id". With CIPSO, this happens. With labeled ipsec, I get "s3-s9". Debugging xinetd, I noticed that when using CIPSO, getpeercon() returns "system_u:object_r:unlabeled_t:s3". When using labeled ipsec, getpeercon() returns "root:sysadm_r:sysadm_ssh_t:s3-s9". I always wondered if getpeercon() would someday lift its head and bite, I just wish it had not been on Valentine's Day. :-) I am concerned about the mls label being returned. So, my question is, how is this suppose to work? Does CIPSO, when given an mls range, like s3-s9, only pass the effective level through in ip options? If so, is this what labeled ipsec should be doing? Should we be setting only the effective level in the SA? If so, that could potentially create even more SAs. Or should xinetd, when given a range, should only set the effective level for the new process? I kinda like this solution best, that is, xinetd setting single effective level. But I don't know if that is correct resolution? Regards, Joy From jbrindle at tresys.com Thu Feb 15 01:48:32 2007 From: jbrindle at tresys.com (Joshua Brindle) Date: Wed, 14 Feb 2007 20:48:32 -0500 Subject: [redhat-lspp] Re: ssh/xinetd/getpeercon??? In-Reply-To: <1171495601.2603.488.camel@faith.austin.ibm.com> References: <1171495601.2603.488.camel@faith.austin.ibm.com> Message-ID: <45D3BBF0.3030901@tresys.com> Joy Latten wrote: > I have been playing with the ssh-mls which gets called through xinetd > when labeled networking is in use and am confused about what I am > seeing. :-) > > My assumption is that when using this feature, the resulting ssh > connection will have single mls level, which is the effective level of > the issuer. > > For example, if I am > uid=500(ealuser) gid=500(ealuser) groups=10(wheel),500(ealuser) > context=staff_u:staff_r:staff_t:s3-s9 > > When I issue ssh -p 222 -l , I expect to see "s3" as my new > mls level in the new ssh connection when I do an "id". > > With CIPSO, this happens. > With labeled ipsec, I get "s3-s9". > > Debugging xinetd, I noticed that when using CIPSO, getpeercon() returns > "system_u:object_r:unlabeled_t:s3". > > When using labeled ipsec, getpeercon() returns > "root:sysadm_r:sysadm_ssh_t:s3-s9". > > I always wondered if getpeercon() would someday lift its head and bite, > I just wish it had not been on Valentine's Day. :-) > I am concerned about the mls label being returned. > > So, my question is, how is this suppose to work? > Does CIPSO, when given an mls range, like s3-s9, only pass > the effective level through in ip options? If so, is this > what labeled ipsec should be doing? Should we be setting only the > effective level in the SA? If so, that could potentially create > even more SAs. Or should xinetd, when given a range, should only > set the effective level for the new process? I kinda like this > solution best, that is, xinetd setting single effective level. But > I don't know if that is correct resolution? > > IMO the entire context should be passed, in CIPSO's case that should be the range, if your clearance is s9 on one machine why wouldn't it be on another that uses the same levels? I'd hate to see userland interpreting ranges like this, it will cause assumptions about the mls policy to be made in userspace. While CIPSO is done entirely in the kernel (i think?) the decision should still not be made outside the security server which is the only part of the system that understands what s2-s9 even means (consider a modified mls policy where the second part of the range is something other than clearance. It is (again, IMO) entirely inappropriate for racoon or xinetd or the CIPSO code to interpret contexts, this issue keeps coming up and the answer should always be that the context is interpreted by the security server exclusively. From sds at tycho.nsa.gov Thu Feb 15 18:43:20 2007 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 15 Feb 2007 13:43:20 -0500 Subject: [redhat-lspp] Re: ssh/xinetd/getpeercon??? In-Reply-To: <1171495601.2603.488.camel@faith.austin.ibm.com> References: <1171495601.2603.488.camel@faith.austin.ibm.com> Message-ID: <1171565000.32574.48.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2007-02-14 at 17:26 -0600, Joy Latten wrote: > I have been playing with the ssh-mls which gets called through xinetd > when labeled networking is in use and am confused about what I am > seeing. :-) > > My assumption is that when using this feature, the resulting ssh > connection will have single mls level, which is the effective level of > the issuer. > > For example, if I am > uid=500(ealuser) gid=500(ealuser) groups=10(wheel),500(ealuser) > context=staff_u:staff_r:staff_t:s3-s9 > > When I issue ssh -p 222 -l , I expect to see "s3" as my new > mls level in the new ssh connection when I do an "id". > > With CIPSO, this happens. > With labeled ipsec, I get "s3-s9". > > Debugging xinetd, I noticed that when using CIPSO, getpeercon() returns > "system_u:object_r:unlabeled_t:s3". > > When using labeled ipsec, getpeercon() returns > "root:sysadm_r:sysadm_ssh_t:s3-s9". > > I always wondered if getpeercon() would someday lift its head and bite, > I just wish it had not been on Valentine's Day. :-) > I am concerned about the mls label being returned. > > So, my question is, how is this suppose to work? > Does CIPSO, when given an mls range, like s3-s9, only pass > the effective level through in ip options? If so, is this > what labeled ipsec should be doing? Should we be setting only the > effective level in the SA? If so, that could potentially create > even more SAs. Or should xinetd, when given a range, should only > set the effective level for the new process? I kinda like this > solution best, that is, xinetd setting single effective level. But > I don't know if that is correct resolution? The labeled networking mechanism should convey the full context when possible (naturally, with a legacy mechanism like CIPSO, we may not have that option except by using something like James Morris' Selopt approach, which naturally won't be compatible with legacy trusted OSes). -- Stephen Smalley National Security Agency From paul.moore at hp.com Thu Feb 15 18:58:10 2007 From: paul.moore at hp.com (Paul Moore) Date: Thu, 15 Feb 2007 13:58:10 -0500 Subject: [redhat-lspp] Re: ssh/xinetd/getpeercon??? In-Reply-To: <45D3BBF0.3030901@tresys.com> References: <1171495601.2603.488.camel@faith.austin.ibm.com> <45D3BBF0.3030901@tresys.com> Message-ID: <200702151358.10230.paul.moore@hp.com> On Wednesday, February 14 2007 8:48:32 pm Joshua Brindle wrote: > Joy Latten wrote: > > I always wondered if getpeercon() would someday lift its head and bite, > > I just wish it had not been on Valentine's Day. :-) > > I am concerned about the mls label being returned. > > > > So, my question is, how is this suppose to work? > > Does CIPSO, when given an mls range, like s3-s9, only pass > > the effective level through in ip options? If so, is this > > what labeled ipsec should be doing? Should we be setting only the > > effective level in the SA? If so, that could potentially create > > even more SAs. Or should xinetd, when given a range, should only > > set the effective level for the new process? I kinda like this > > solution best, that is, xinetd setting single effective level. But > > I don't know if that is correct resolution? > > IMO the entire context should be passed, in CIPSO's case that should be > the range, if your clearance is s9 on one machine why wouldn't it be on > another that uses the same levels? I'd hate to see userland interpreting > ranges like this, it will cause assumptions about the mls policy to be > made in userspace. While CIPSO is done entirely in the kernel (i think?) > the decision should still not be made outside the security server which > is the only part of the system that understands what s2-s9 even means > (consider a modified mls policy where the second part of the range is > something other than clearance. > > It is (again, IMO) entirely inappropriate for racoon or xinetd or the > CIPSO code to interpret contexts, this issue keeps coming up and the > answer should always be that the context is interpreted by the security > server exclusively. The CIPSO protocol does not have any concept of a MLS "range", it only allows for packets to be labeled with a single sensitivity level and category set. Currently the NetLabel code only supports a single MLS level. There are two reasons for this: 1. I tend to think packets are objects and as we have seen through numerous discussions, "ranged" objects don't make much sense. 2. NetLabel doesn't currently support any protocols which provide a "ranged" packet label. The decision to use the lower/effective/zero-element-in-the-range-array when setting the security attributes of a socket using NetLabel is done in the SELinux code, not the general NetLabel code and not userspace. -- paul moore linux security @ hp From latten at austin.ibm.com Thu Feb 15 19:37:18 2007 From: latten at austin.ibm.com (Joy Latten) Date: Thu, 15 Feb 2007 13:37:18 -0600 Subject: [redhat-lspp] Re: ssh/xinetd/getpeercon??? In-Reply-To: <45D3BBF0.3030901@tresys.com> References: <1171495601.2603.488.camel@faith.austin.ibm.com> <45D3BBF0.3030901@tresys.com> Message-ID: <1171568238.2603.519.camel@faith.austin.ibm.com> On Wed, 2007-02-14 at 20:48 -0500, Joshua Brindle wrote: > Joy Latten wrote: > > I have been playing with the ssh-mls which gets called through xinetd > > when labeled networking is in use and am confused about what I am > > seeing. :-) > > > > My assumption is that when using this feature, the resulting ssh > > connection will have single mls level, which is the effective level of > > the issuer. > > > > For example, if I am > > uid=500(ealuser) gid=500(ealuser) groups=10(wheel),500(ealuser) > > context=staff_u:staff_r:staff_t:s3-s9 > > > > When I issue ssh -p 222 -l , I expect to see "s3" as my new > > mls level in the new ssh connection when I do an "id". > > > > With CIPSO, this happens. > > With labeled ipsec, I get "s3-s9". > > > > Debugging xinetd, I noticed that when using CIPSO, getpeercon() returns > > "system_u:object_r:unlabeled_t:s3". > > > > When using labeled ipsec, getpeercon() returns > > "root:sysadm_r:sysadm_ssh_t:s3-s9". > > > > I always wondered if getpeercon() would someday lift its head and bite, > > I just wish it had not been on Valentine's Day. :-) > > I am concerned about the mls label being returned. > > > > So, my question is, how is this suppose to work? > > Does CIPSO, when given an mls range, like s3-s9, only pass > > the effective level through in ip options? If so, is this > > what labeled ipsec should be doing? Should we be setting only the > > effective level in the SA? If so, that could potentially create > > even more SAs. Or should xinetd, when given a range, should only > > set the effective level for the new process? I kinda like this > > solution best, that is, xinetd setting single effective level. But > > I don't know if that is correct resolution? > > > > > IMO the entire context should be passed, in CIPSO's case that should be > the range, if your clearance is s9 on one machine why wouldn't it be on > another that uses the same levels? I'd hate to see userland interpreting > ranges like this, it will cause assumptions about the mls policy to be > made in userspace. While CIPSO is done entirely in the kernel (i think?) > the decision should still not be made outside the security server which > is the only part of the system that understands what s2-s9 even means > (consider a modified mls policy where the second part of the range is > something other than clearance. > > It is (again, IMO) entirely inappropriate for racoon or xinetd or the > CIPSO code to interpret contexts, this issue keeps coming up and the > answer should always be that the context is interpreted by the security > server exclusively. > I think I became confused because when I saw that getpeercon() returned single mls level (s3) for CIPSO and a range (s3-s9) for labeled ipsec. I knew the user:role:type would perhaps be different, but I was not expecting the mls level too. I guess I learned something new about the cipso implementation. :-) It seems everything is working ok. Klaus W. says it is ok that ssh-mls uses a range for labeled ipsec and just the effective level for cipso. Both protocols appear to work correctly with the xinetd/ssh-mls implementation. Joy From loulwas at us.ibm.com Fri Feb 16 17:00:07 2007 From: loulwas at us.ibm.com (Loulwa Salem) Date: Fri, 16 Feb 2007 11:00:07 -0600 Subject: [redhat-lspp] [Reminder] LSPP Bug Telecon Mon., Feb. 19 Message-ID: <45D5E317.1050001@us.ibm.com> The LSPP Development Telecon is now the LSPP Bug Telecon Thanks to all who participated in the LSPP Development Telecon. It has mutated into the LSPP Bug Telecon. We will iterate over a list of bugs affecting features developed for LSPP. IBM continues host the telecon every Monday at 21:00 UTC. 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 after review by the existing participants. Please note that the number of attendees may be limited by our call center's restrictions on maximum lines per conference. -- Loulwa Salem -- IBM Linux Technology Center From sgrubb at redhat.com Mon Feb 19 16:48:02 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Mon, 19 Feb 2007 11:48:02 -0500 Subject: [redhat-lspp] lspp 65 kernel released Message-ID: <200702191148.02065.sgrubb@redhat.com> Hi, The lspp.65 kernel has been published to the lspp yum repo at: http://people.redhat.com/sgrubb/files/lspp - 223918: audit logs bogus obj label in some PATH records - 223919: audit does not log obj label when opening an existing POSIX message queue - 224080: audit does not log obj label for mq_timedreceive/mq_timedsend - ??????: audit inode for all xattr syscalls - ??????: match audit name data (might roll into 223919 224080) - 225328: ipsec drops first packet when using IKE daemon - revert fix for 222033 xfrm_audit_log panic - 228422: cleanup xfrm_audit_log interface Please let me know if there any problems with this kernel. -Steve From vyekkirala at trustedcs.com Mon Feb 19 17:37:40 2007 From: vyekkirala at trustedcs.com (Venkat Yekkirala) Date: Mon, 19 Feb 2007 11:37:40 -0600 Subject: [redhat-lspp] RE: Deleting xfrms In-Reply-To: <1171323597.2603.445.camel@faith.austin.ibm.com> Message-ID: <000c01c7544c$a87906a0$cc0a010a@tcssec.com> I see this bug crept in here: http://marc.theaimsgroup.com/?l=linux-netdev&m=114956850915839&w=2 Are you planning to fix this or did you want me to? > -----Original Message----- > From: Joy Latten [mailto:latten at austin.ibm.com] > Sent: Monday, February 12, 2007 5:40 PM > To: jmorris at namei.org; vyekkirala at TrustedCS.com > Cc: selinux at tycho.nsa.gov; redhat-lspp at redhat.com > Subject: Deleting xfrms > > > I was looking at a patch D.Miller posted for xfrm_audit_log() > and could not help but notice that in pfkey_spddelete() and > xfrm_get_policy() we delete policy first and then check to see if we > have permissions to. Am I missing the original intentions or > is this incorrect? Shouldn't it be check the permissions > first and then > call xfrm_policy_bysel_ctx()? > > pfkey_spddelete() in af_key.c: > > xp = xfrm_policy_bysel_ctx(XFRM_POLICY_TYPE_MAIN, > pol->sadb_x_policy_dir-1, > &sel, tmp.security, 1); > security_xfrm_policy_free(&tmp); > > xfrm_audit_log(audit_get_loginuid(current->audit_context), 0, > AUDIT_MAC_IPSEC_DELSPD, (xp) ? 1 : 0, > xp, NULL); > > if (xp == NULL) > return -ENOENT; > > err = 0; > > if ((err = security_xfrm_policy_delete(xp))) > goto out; > c.seq = hdr->sadb_msg_seq; > c.pid = hdr->sadb_msg_pid; > c.event = XFRM_MSG_DELPOLICY; > km_policy_notify(xp, pol->sadb_x_policy_dir-1, &c); > > > xfrm_get_policy() in xfrm_user.c is very similar. > > Regards, > Joy > From eparis at redhat.com Mon Feb 19 17:47:09 2007 From: eparis at redhat.com (Eric Paris) Date: Mon, 19 Feb 2007 12:47:09 -0500 Subject: [redhat-lspp] RE: Deleting xfrms In-Reply-To: <000c01c7544c$a87906a0$cc0a010a@tcssec.com> References: <000c01c7544c$a87906a0$cc0a010a@tcssec.com> Message-ID: <1171907230.10265.12.camel@localhost.localdomain> On Mon, 2007-02-19 at 11:37 -0600, Venkat Yekkirala wrote: > I see this bug crept in here: > > http://marc.theaimsgroup.com/?l=linux-netdev&m=114956850915839&w=2 > > Are you planning to fix this or did you want me to? Actually I was going to take a stab at it this afternoon. But I won't complain if you beat me to it! -Eric From latten at austin.ibm.com Mon Feb 19 19:10:23 2007 From: latten at austin.ibm.com (Joy Latten) Date: Mon, 19 Feb 2007 13:10:23 -0600 Subject: [redhat-lspp] RE: Deleting xfrms In-Reply-To: <1171907230.10265.12.camel@localhost.localdomain> References: <000c01c7544c$a87906a0$cc0a010a@tcssec.com> <1171907230.10265.12.camel@localhost.localdomain> Message-ID: <1171912223.2603.555.camel@faith.austin.ibm.com> On Mon, 2007-02-19 at 12:47 -0500, Eric Paris wrote: > On Mon, 2007-02-19 at 11:37 -0600, Venkat Yekkirala wrote: > > I see this bug crept in here: > > > > http://marc.theaimsgroup.com/?l=linux-netdev&m=114956850915839&w=2 > > > > Are you planning to fix this or did you want me to? > > Actually I was going to take a stab at it this afternoon. But I won't > complain if you beat me to it! > If either of you fix it, it would be great to me. I am currently working on the loopback patch. So far things are looking ok... if my stress tests continue with no errors, I will send the patches to ipsec-tools tomorrow for review. Next is the "ipsec dropping first packet", see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225328 I encountered problems when I tried to patch the 64 kernel a few weeks ago. I could not get labeled ipsec to work... hopefully there will be more success in lspp 65 kernel. Will try the lspp.65 patch next. Also, when I tried the patch in upstream kernel, my kernel panic'd because of https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228409 so I have not been able to make much progress with this patch in either upstream or lspp kernel. Also, I only saw panic in upstream kernel, not lspp 64 kernel at the time. Thanks!!!!! Joy From latten at austin.ibm.com Tue Feb 20 18:25:54 2007 From: latten at austin.ibm.com (Joy Latten) Date: Tue, 20 Feb 2007 12:25:54 -0600 Subject: [redhat-lspp] labeled ipsec status Message-ID: <1171995954.2603.563.camel@faith.austin.ibm.com> A 16 hour stress test run of labeled ipsec completed successfully on the lspp 65 kernel. Will start a regular ipsec one tonight. With the above stress test I included the patched racoon to work over loopback and included a 16-hour stress run of labeled ipsec over loopback. While the tests completed successfully and no errors in the log file from racoon, I noticed that regular (not loopback SAs) were being created twice instead of once. So, I need to investigate this and see why. Regards, Joy From loulwas at us.ibm.com Tue Feb 20 22:49:55 2007 From: loulwas at us.ibm.com (Loulwa Salem) Date: Tue, 20 Feb 2007 16:49:55 -0600 Subject: [redhat-lspp] LSPP Development Telecon 02/19/2007 Minutes Message-ID: <45DB7B13.50006@us.ibm.com> 02/19/2007 lspp Meeting Minutes: =============================== Attendees Loulwa Salem (IBM) - LS Debora Velarde (IBM) - DV Michael Thompson (IBM) - MT Joy Latten (IBM) - JL Kylene J Hall (IBM) - KH Irina Boverman (Red Hat) - IB Steve Grubb (Red Hat) - SG Dan Walsh (Red Hat) - DW Eric Paris (Red Hat) - EP Lisa Smith (HP) - LMS Klaus Weidner (Atsec) - KW Chad Hanson (TCS) - CH Ted Toth - TT Agenda: Agenda and Meeting Formats Bug Discussion Around the Room RHEL 5+ Packages: kernel-2.6.18-6.el5.lspp.64 kernel-devel-2.6.18-6.el5.lspp.64 kernel-doc-2.6.18-6.el5.lspp.64 mcstrans-0.2.1-1.el5 selinux-policy-2.4.6-32.el5 selinux-policy-devel-2.4.6-32.el5 selinux-policy-mls-2.4.6-32.el5 selinux-policy-strict-2.4.6-32.el5 selinux-policy-targeted-2.4.6-32.el5 audit vixie-cron LS: George is out on a family emergency, I don't know when he'll be back. I'll moderate the meeting today. Thanks Irena for providing me with an updated list of bugs for the agenda. George sent me an update on the list of packages to include vixie-cron and audit KW: cron from Dan, and audit from Steve is that it? What versions should we have? LS: He didn't have version numbers .. just the package name. SG: we are one day away from FC 7, so that took some time from me, I've been looking at bugs, to make a long story short, I have not built an audit lspp package yet, should get to it this week. KW: are there patches that we need to try separately, is this 1.3 or a version update? SG: I have 2 patches to back port and third item that gets rid of using id program from init script and uses shell script variable instead, useful if user is using a network device. KW: wanted to be clear if we are doing installation, what should we be using. should we keep the rhel5 rc version SG: yes, and the audit package I'll get out this week is one number higher, the version should be -2. there is no intention of moving to 1.4 or 1.5. KW: Are there any visible changes, any known failures we should be expecting with current versions. just so we know if things don't work, what the new version would do. SG: There are three patches .. KW: are these bugs in relation with list we'll go over, I can wait SG: well basically, ausearch -se didn't work at all, so I have a simple fix for that. The -se option should search on either object or subject context, it was doing "and" instead of "or" so it wasn't working. There is a bug fix I mentioned when replying to Stephen Smalley, it's the perm fix in libaudit, not being able to audit by context and certain permissions. then there is the euid update, to take the call to id program out of the init script for network devices. Apparently there is quite few people that use network devices. KW: I see the bug 226780. Are there any more for the issues you mentioned LS: let's go through the bugs then and see what those cover, then discuss what's left after that. SG: there are bugzillas that are associated with the others but not lspp related. do you want them KW: don't need them if they don't affect us. Alias Sev Pri Plt Assignee Status Resolution Summary 218386 nor nor pow ASSI LSPP: labeled ipsec does not work over loopback JL: made some progress on that one, the errors I was seeing in log file are now fixed. This morning, I ran a stress test and didn't see errors in log file. Tonight before I leave, I'll start several stress tests (using .65 kernel), one over loopback, eth0, and eth1. If all looks fine, I'll send the patch to ipsec-tools and leave it to them for review. LS: so is it fixed now? JL: I won't consider it fixed until I see what they say. My base is the patch that Paul sent out. 223532 nor nor All ASSI [LSPP] crontab manpages reference older environment variable KW: last comment in bug is from Irena saying it is in the modified state. SG: it turns out no one really applied the patch and built the package. I'll try to get that moving this week. LS: should we expect another cron package then Steve SG: yes, the bug should be fixed before we get it in modified state. 223840 hig nor All NEW [LSPP] getfacl fails to correctly display all information... SG: The maintainer created a patch over the weekend, klaus reviewed and it looks good. The next step is to build package. The "acl" package is going to need to be carried. KW: can we make the oldest bug about this issue public (bug # 128265) IB: I'll try to do that, but couldn't change it myself SG: that one was related to rhel4. it is in errata system, so we don't have control over it. KW: if it causes problems then ignore it SG: only thing we can do is clone it 223864 nor nor All NEW LSPP: Exceptions to expected audit behavior should be doc... LS: What did we agree to do with this one? SG: we talked about putting proper documentation for it in user's guide. LS: who's taking action on that? KW: there are multiple guides, I'll take action on that for the guide I am maintaining. Others need to do the same. 223918 nor nor All ASSI LSPP: audit logs bogus obj label in some PATH records EP: fix for that should be in lspp.65 KW: I see comment on RH bug stating that. LS: great .. we'll test it. LMS: I had a related question, there were couple of bugs that Amy worked on, should we be posting bugzillas for those EP: at the moment I have all the bugzillas I want 223919 nor nor All ASSI LSPP: audit does not log obj label when opening an existi... EP: all the audit bugs are related, Al is looking at the one about tracing signals. The other one # 228366, I have a patch for it and we need more review on the patch. For # 228384, there is no patch and not sure who's working on it IB: I thought we'll get Al to look at it SG: I didn't run across Al the last couple of days. KW: do we have plan B is case we don't reach Al SG: Amy will be back next week, and we can talk to her then. Either way, I think Al will get involved in writing it or help review it. I'll see if I can get hold of him. EP: everything else that says audit in subject, there is patch for and should be in .65 kernel. LS: Ok, Let me go through the list for those bugs and make sure I got them straight. 224080 nor nor All NEW LSPP: audit does not log obj label for mq_timedreceive/mq... EP: closed as duplicate of 223919 225328 nor nor All ASSI LSPP: ipsec drops first packet when using IKE daemon JL: I loaded the .65 kernel and it actually worked, I'm happy with it. I tried labeled ipsec, and looked like it was working fine. I am currently running sniff test and it seems to be going well. I'll run it over night and if it works fine, tomorrow I'll kick off a regular ipsec test to make sure it didn't regress. Only concern, it needs to work in lspp and upstream kernel, and when I patched upstream kernel (2.6.20) it panicked. I opened the bug about audit log task context problem. I could try the latest git kernel, but I'm thinking I need that audit patch before I make additional progress. On our lspp kernel I don't see that audit problem. LS: should we keep this bug open until you try both kernels then JL: yes, this bug still needs lots of testing. 226780 nor nor All ASSI LSPP: audit of writes to files of bin_t produces no records KW: Steve talked about it earlier. 228107 nor nor All NEW [LSPP] Labels for labeled printing don't linewrap LS: Matt was working on it, do we have an update? LMS: I believe he is still working on that, but I have no status. 228366 nor nor All ASSI LSPP: audit does not log obj label for signal recipient LS: Already have patch for and in .65 kernel (per Eric's above comments) 228384 nor nor All ASSI LSPP: audit does not log obj label for traced process LS: There is no patch for this one. Will get Al to take a look at it or follow up with Amy when she gets back. (per Eric's above comments) 228398 med nor s39 ASSI LSPP: Not able to ssh into the machine with multiple cate... KW: There were two issues, it didn't work on labeled translation which is fixed now. Second is if you have large list of categories it didn't work. That one is less critical since it failed securely and doesn't need to be fixed for certification. SG: I think we want to fix that one, it's an easy fix. It can check length .. there is a way of reading polyinstantiated directories with large number of categories. I'll put these comments in bugzilla, and I'll ask Tomas if he can look at it. he has been traveling, and doubt he did anything, unless he worked on it earlier today. KW: I think currently it's based on using translated context for file name, just wanted to make sure everyone knew that and everyone is Ok with it. This has side effects if mcstrans breaks or if you use mappings DW: It should be working on raw context, so if it's on translated, I think that's wrong. KW: are you saying it's intended to, or what you expect it to be using is raw one DW: I would expect it to work with raw context KW: so we still need an action to verify what it's actually doing LS: who owns this bug SG: Tomas Mraz 228422 med nor All ASSI LSPP: cleanup xfrm_audit_log interface SG: last I saw is an exchange between Stephen and Al about kernel code. Smalley said we should use a different API. It did look like Al is working on it. need to follow up with him to see if he has a patch. JL: I think that's the one David Miller posted a patch for. I think I opened that one specifically because he didn't like the way I wrote it. so he wanted to clean it up. I think that one is in 65 kernel. SG: not sure which bug Al is chasing then JL: Al is working on the one where we transform audit log calls (audit_log_cntxt). that's what caused the kernel panic in the upstream kernel. One Al is working on is # 228409. 228557 med nor All ASSI LSPP: In labeled ipsec, permissions are checked after del... EP: I got patch finished today, so you'll see something in the morning for that JL: Venkat also volunteered to look at it which was great EP: I'll be taking care of that one, but I have nothing to report yet. 228927 med nor s39 NEW LSPP: odd audit argument on some 32 bit syscalls KW: we discussed this as well, it is a documentation update KH: most of the information is in issue tracker, so it's been explained. It needs to be documented LS: Ok, so this needs to be in the guide as well LS: We are done with our bug list, are there any more issues? IB: bug # 229094, last comment says the fix in in .65 KW: I think the patch is meant for .65 but not in it yet. IB: Eric, is it in the .65 kernel? EP: yes it is in .65 kernel KW: there are 2 issue. One that polyinstantiation should use raw category and labels instead of translated, if we want to change it, we need a bug. Related to this, with the latest mcstransd I don't get any labels translated. I heard unofficially others are seeing this. I don't think there is a bug report for this. DW: there is bug, but you need to grab the latest package from my people page SG: maybe need a bug to track it. DW: what version of mctrans are you running KW: 0.22.1.el5, which I think is the latest DW: I believe the fixed one is 0.2.3-1 KW: I see it now, Ok, so I forgot to pick up the latest one. Do we need a bug to make sure it ends up in rhel 5, or are you tracking this internally DW: I'm tracking it internally. JL: I just opened a bug # 229278, I was running labeled ipsec ssh-mls, if I am a regular user with s2-s5, when I issue ssh -p 222 to user (s3-s9), my incoming connection is s2-s5, I am able to log in to that user and I get to be s3-s5. I showed it to klaus and since my incoming level was s2, I shouldn't have be able to log in. KW: it seems to be silently upgrading the level. With labeled networking, your session is always at effective level and not at the higher level DW: so you think user should be denied. KW: yes, we can try with cipso as well. LS: I'll try with cipso KW: I think it'll work with cipso, ipsec is trying to be helpful and trying to upgrade DW: could be that either libselinux or ssh doing something wrong. LS: any other issues any one would like to bring up? SG: one thing to point out, over the next 2 days, I'll be a bit distracted getting changes done for fC7, Wednesday will probably be back working on lspp items. I am not sure if Tomas can jump on the ssh issue, it depends on what he has to do for fC7 as well. other than that we should be back on lspp on Wed. LS: ok, Anything else? .. alright thanks everyone, We'll adjourn. From loulwas at us.ibm.com Fri Feb 23 21:08:01 2007 From: loulwas at us.ibm.com (Loulwa Salem) Date: Fri, 23 Feb 2007 15:08:01 -0600 Subject: [redhat-lspp] [Reminder] LSPP Bug Telecon Mon., Feb. 26 Message-ID: <45DF57B1.3050606@us.ibm.com> The LSPP Development Telecon is now the LSPP Bug Telecon Thanks to all who participated in the LSPP Development Telecon. It has mutated into the LSPP Bug Telecon. We will iterate over a list of bugs affecting features developed for LSPP. IBM continues host the telecon every Monday at 21:00 UTC. 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 after review by the existing participants. Please note that the number of attendees may be limited by our call center's restrictions on maximum lines per conference. -- Loulwa Salem -- IBM Linux Technology Center From sgrubb at redhat.com Sun Feb 25 20:04:00 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Sun, 25 Feb 2007 15:04:00 -0500 Subject: [redhat-lspp] lspp 66 kernel released Message-ID: <200702251504.01066.sgrubb@redhat.com> Hi, The lspp.66 kernel has been published to the lspp yum repo at: http://people.redhat.com/sgrubb/files/lspp - audit logs bogus obj label in some PATH records (amg) [223918] - audit records for some f*xattr syscalls don't inclu (amg) [229094] - audit does not log obj label when opening an existi (amg) [223919] - ipsec drops first packet when using IKE daemon (dmiller) [225328] - **drop patch #221202 for BZ 222033 to allow the upstream fix below - cleanup xfrm_audit_log interface (dmiller) [228422] - flow cache entries remain valid even after selinux (venkat) [229527] - memory leak in flow cache code (venkat) [229528] - audit does not log obj label for signal recipient (amg) [228366] - labeled ipsec, permissions are checked after deleting the policy (eparis) [228557] - pfkey_spdget does not audit xrfm policy changes (eparis) [229720] - pfkey_delete and xfrm_del_sa audit hook is misplaced (eparis) [229732] Please let me know if there any problems with this kernel. -Steve From sgrubb at redhat.com Mon Feb 26 00:28:40 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Sun, 25 Feb 2007 19:28:40 -0500 Subject: [redhat-lspp] lspp 66 kernel released In-Reply-To: <200702251504.01066.sgrubb@redhat.com> References: <200702251504.01066.sgrubb@redhat.com> Message-ID: <200702251928.40225.sgrubb@redhat.com> On Sunday 25 February 2007 15:04:00 Steve Grubb wrote: > Please let me know if there any problems with this kernel. I just saw a panic on shutdown with this kernel that the lspp.65 kernel does not have: Kernel panic - not syncing: nmi watchdog BUG: warning at kernel/panic.c:137/panic() (Not tainted) Call Trace: [] panic+0x1e3/0x1f4 [] _show_stack_0xdb/0xea [] show_registers+0xe4/0x100 [] die_nmi+0x66/0xa3 [] nmi_watchdog_tick+0x105/0x1a6 [] default_do_nmi+0x86/0x214 [] do_nmi_0x43/0x61 [] nmi+0x7f/0x88 [] sock_destroy_inode+0x0/0x10 []__write_lock_failed+0x9/0x20 <> [] _write_lock_irq+0xf/0x10 [] do_exit_0x548/0x8b1 [] cpuset_exit+0x0/0x6c [] get_signal_to_deliver+0x427/0x456 [] do_notify_resume+0x9c/0x7a9 [] enqueue_hrtimer+0x55/0x70 [] hrtimer_start+0xbc/0xce [] audit_syscall_exit+0x2cd/0x2ec [] int_signal+0x12/0x17 From eparis at redhat.com Mon Feb 26 19:33:40 2007 From: eparis at redhat.com (Eric Paris) Date: Mon, 26 Feb 2007 14:33:40 -0500 Subject: [redhat-lspp] lspp 66 kernel released In-Reply-To: <200702251928.40225.sgrubb@redhat.com> References: <200702251504.01066.sgrubb@redhat.com> <200702251928.40225.sgrubb@redhat.com> Message-ID: <1172518420.22087.1.camel@localhost.localdomain> I've been rebooting the .67 kernel (same as .65 but with more debug features turned on and I expect to see this in your repo soon) over and over on my one machine and haven't seen any problems. Can you tell me what your audit rules look like and what operations you may be done on this before this panic? -Eric On Sun, 2007-02-25 at 19:28 -0500, Steve Grubb wrote: > On Sunday 25 February 2007 15:04:00 Steve Grubb wrote: > > Please let me know if there any problems with this kernel. > > I just saw a panic on shutdown with this kernel that the lspp.65 kernel does > not have: > > Kernel panic - not syncing: nmi watchdog > BUG: warning at kernel/panic.c:137/panic() (Not tainted) > > Call Trace: > [] panic+0x1e3/0x1f4 > [] _show_stack_0xdb/0xea > [] show_registers+0xe4/0x100 > [] die_nmi+0x66/0xa3 > [] nmi_watchdog_tick+0x105/0x1a6 > [] default_do_nmi+0x86/0x214 > [] do_nmi_0x43/0x61 > [] nmi+0x7f/0x88 > [] sock_destroy_inode+0x0/0x10 > []__write_lock_failed+0x9/0x20 > <> [] _write_lock_irq+0xf/0x10 > [] do_exit_0x548/0x8b1 > [] cpuset_exit+0x0/0x6c > [] get_signal_to_deliver+0x427/0x456 > [] do_notify_resume+0x9c/0x7a9 > [] enqueue_hrtimer+0x55/0x70 > [] hrtimer_start+0xbc/0xce > [] audit_syscall_exit+0x2cd/0x2ec > [] int_signal+0x12/0x17 > > -- > redhat-lspp mailing list > redhat-lspp at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-lspp From eparis at redhat.com Mon Feb 26 19:37:46 2007 From: eparis at redhat.com (Eric Paris) Date: Mon, 26 Feb 2007 14:37:46 -0500 Subject: [redhat-lspp] lspp 66 kernel released In-Reply-To: <1172518420.22087.1.camel@localhost.localdomain> References: <200702251504.01066.sgrubb@redhat.com> <200702251928.40225.sgrubb@redhat.com> <1172518420.22087.1.camel@localhost.localdomain> Message-ID: <1172518666.22087.3.camel@localhost.localdomain> On Mon, 2007-02-26 at 14:33 -0500, Eric Paris wrote: > I've been rebooting the .67 kernel (same as .65 meant to say same as .66 -Eric From sgrubb at redhat.com Mon Feb 26 19:42:25 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Mon, 26 Feb 2007 14:42:25 -0500 Subject: [redhat-lspp] lspp 66 kernel released In-Reply-To: <1172518420.22087.1.camel@localhost.localdomain> References: <200702251504.01066.sgrubb@redhat.com> <200702251928.40225.sgrubb@redhat.com> <1172518420.22087.1.camel@localhost.localdomain> Message-ID: <200702261442.25786.sgrubb@redhat.com> On Monday 26 February 2007 14:33, Eric Paris wrote: > I've been rebooting the .67 kernel (same as .65 but with more debug > features turned on and I expect to see this in your repo soon) over and > over on my one machine and haven't seen any problems. ?Can you tell me > what your audit rules look like and what operations you may be done on > this before this panic? It just has 2 audit rules, one for auditing sethostname and one watching /etc/localtime. I had just installed new version of libselinux and was rebooting to see if it worked OK. (It didn't but that's another story.) I am on a 64 bit machine and only saw it once on shutdown. The machine is 100% rawhide except the kernel. But user space shouldn't cause a NMI kernel timeout. -Steve From sgrubb at redhat.com Mon Feb 26 23:26:43 2007 From: sgrubb at redhat.com (Steve Grubb) Date: Mon, 26 Feb 2007 18:26:43 -0500 Subject: [redhat-lspp] lspp 67 kernel released Message-ID: <200702261826.43416.sgrubb@redhat.com> Hi, The lspp.67 kernel is being published to the lspp yum repo at: http://people.redhat.com/sgrubb/files/lspp This is essentially the lspp.66 kernel with debug options turned on. Please let me know if there any problems with this kernel. -Steve From loulwas at us.ibm.com Tue Feb 27 00:17:19 2007 From: loulwas at us.ibm.com (Loulwa Salem) Date: Mon, 26 Feb 2007 18:17:19 -0600 Subject: [redhat-lspp] different cipso mapping behavior Message-ID: <45E3788F.5060200@us.ibm.com> Hi Paul, After the meeting, I went back to try some cipso tests and noticed the following behavior that didn't use to happen before .. I am on the latest RHEL drop with the .65 kernel, latest policy .38, and netlabel_tools-0.17-9.el5 I was trying to test the cipso mappings and that a connection is granted/denied correctly between two systems when mappings are in place. Here is what I had a problem with .. I set up a system with following rules netlabelctl cipsov4 add std doi:1 tags:1 levels:2=1 categories:2=1 netlabelctl map del default netlabelctl map add default protocol:cipsov4,1 Now I try to log in (note I already have a session on the system and I use that one to log in, so its coming through localhost) ssh -l testuser/user_r/s2:c2-s2:c2 localhost The above command hangs .. Looking at the output of tcpdump (tcpdump -v -i lo) I see an ICMP error (output at end of this message). I also checked, and there were no relevant audit records or anything useful in /var/log/messages or /var/log/secure. In the past this test used to pass.. so I was wondering if this is an intended change, or something is not working. To better understand what's happening, and see if mapping are really working, I tried the following .. Unset cipso settings logged on to my system as above context from another existing ssh window then setup cipso again. I verified that the mappings work fine by trying to connect to my system from an s1 connection which succeeded as per the mappings. I also tried the following ssh and all hung (with similar ICMP error output) ssh -l testuser/user_r/s1:c1-s1:c1 localhost ssh -l testuser/user_r/ localhost ssh -l testuser localhost ssh -p 222 -l testuser localhost should trying to ssh into the system with these cipso mapping settings enabled hang or be denied, if so why? Thanks, - Loulwa >>> tcpdump output <<< [root/abat_r/SystemLow at joy-hv4 framework]# tcpdump -vv -i lo tcpdump: listening on lo, link-type EN10MB (Ethernet), capture size 96 bytes 13:36:05.473874 IP (tos 0x0, ttl 64, id 20931, offset 0, flags [DF], proto: TCP (6), length: 72, options ( unknown (134) len 10EOL (0) len 1 )) localhost.localdomain.58117 > localhost.localdomain.ssh: S, cksum 0x2c1a (correct), 3261345366:3261345366(0) win 32792 13:36:05.474246 IP (tos 0xc0, ttl 64, id 52022, offset 0, flags [none], proto: ICMP (1), length: 112, options ( unknown (134) len 10EOL (0) len 1 )) localhost.localdomain > localhost.localdomain: ICMP parameter problem - octet 29, length 80 IP (tos 0x0, ttl 64, id 20931, offset 0, flags [DF], proto: TCP (6), length: 72, options ( unknown (134) len 10EOL (0) len 1 )) localhost.localdomain.58117 > localhost.localdomain.ssh: tcp 40 [bad hdr length 0 - too short, < 20] 2 packets captured 6 packets received by filter 0 packets dropped by kernel From paul.moore at hp.com Tue Feb 27 14:40:45 2007 From: paul.moore at hp.com (Paul Moore) Date: Tue, 27 Feb 2007 09:40:45 -0500 Subject: [redhat-lspp] Re: different cipso mapping behavior In-Reply-To: <45E3788F.5060200@us.ibm.com> References: <45E3788F.5060200@us.ibm.com> Message-ID: <200702270940.45898.paul.moore@hp.com> On Monday, February 26 2007 7:17:19 pm Loulwa Salem wrote: > Hi Paul, > After the meeting, I went back to try some cipso tests and noticed the > following behavior that didn't use to happen before .. > I am on the latest RHEL drop with the .65 kernel, latest policy .38, and > netlabel_tools-0.17-9.el5 > > I was trying to test the cipso mappings and that a connection is > granted/denied correctly between two systems when mappings are in place. > > Here is what I had a problem with .. > > I set up a system with following rules > netlabelctl cipsov4 add std doi:1 tags:1 levels:2=1 categories:2=1 > netlabelctl map del default > netlabelctl map add default protocol:cipsov4,1 > > Now I try to log in (note I already have a session on the system and I use > that one to log in, so its coming through localhost) > ssh -l testuser/user_r/s2:c2-s2:c2 localhost > > The above command hangs .. Looking at the output of tcpdump (tcpdump -v -i > lo) I see an ICMP error (output at end of this message). I also checked, > and there were no relevant audit records or anything useful in > /var/log/messages or /var/log/secure. Something odd is happening as based on the packet dump the CIPSO option is 10 bytes long, which for tag type 1 would indicate a lack of categories yet you are using "c2" which should map to CIPSO category "1" based on your DOI settings. To further complicate things, assuming I've done my quick math correctly the ICMP parameter error is pointing at the CIPSO length field in the tag. It's hard to say for certain at this point, but it kinda looks like the packet is not being created correctly. Please retry with the following CIPSO DOI configuration: # netlabelctl cipsov4 add pass doi:1 tags:1 > In the past this test used to pass.. so I was wondering if this is an > intended change, or something is not working. Which was the latest kernel which worked correctly? -- paul moore linux security @ hp From loulwas at us.ibm.com Tue Feb 27 16:11:54 2007 From: loulwas at us.ibm.com (Loulwa Salem) Date: Tue, 27 Feb 2007 10:11:54 -0600 Subject: [redhat-lspp] Re: different cipso mapping behavior In-Reply-To: <200702270940.45898.paul.moore@hp.com> References: <45E3788F.5060200@us.ibm.com> <200702270940.45898.paul.moore@hp.com> Message-ID: <45E4584A.3030408@us.ibm.com> Paul Moore wrote: > On Monday, February 26 2007 7:17:19 pm Loulwa Salem wrote: ... > > Something odd is happening as based on the packet dump the CIPSO option is 10 bytes long, which for tag type 1 would indicate a lack of categories yet you are using "c2" which should map to CIPSO category "1" based on your DOI settings. To further complicate things, assuming I've done my quick math correctly the ICMP parameter error is pointing at the CIPSO length field in the tag. It's hard to say for certain at this point, but it kinda looks like the packet is not being created correctly. > > Please retry with the following CIPSO DOI configuration: > > # netlabelctl cipsov4 add pass doi:1 tags:1 The setting above works fine .. that's what I've been using for most of my test cases. I am able to log in to the system with above setting enabled. > > >> In the past this test used to pass.. so I was wondering if this is an >> intended change, or something is not working. > > > > Which was the latest kernel which worked correctly? > I don't know for sure .. I constantly update my systems to latest drops and lspp kernels. I am in the process of trying older kernels to see where it last worked. so far .65 and .64 don't work... will update more as I try a few others .. Thanks, - Loulwa From paul.moore at hp.com Tue Feb 27 16:20:17 2007 From: paul.moore at hp.com (Paul Moore) Date: Tue, 27 Feb 2007 11:20:17 -0500 Subject: [redhat-lspp] Re: different cipso mapping behavior In-Reply-To: <45E4584A.3030408@us.ibm.com> References: <45E3788F.5060200@us.ibm.com> <200702270940.45898.paul.moore@hp.com> <45E4584A.3030408@us.ibm.com> Message-ID: <200702271120.17741.paul.moore@hp.com> On Tuesday, February 27 2007 11:11:54 am Loulwa Salem wrote: > Paul Moore wrote: > > On Monday, February 26 2007 7:17:19 pm Loulwa Salem wrote: > > ... > > > Something odd is happening as based on the packet dump the CIPSO option > > is 10 > > bytes long, which for tag type 1 would indicate a lack of categories yet > you are using "c2" which should map to CIPSO category "1" based on your DOI > settings. To further complicate things, assuming I've done my quick math > correctly the ICMP parameter error is pointing at the CIPSO length field in > the tag. It's hard to say for certain at this point, but it kinda looks > like the packet is not being created correctly. > > > Please retry with the following CIPSO DOI configuration: > > > > # netlabelctl cipsov4 add pass doi:1 tags:1 > > The setting above works fine .. that's what I've been using for most of my > test cases. I am able to log in to the system with above setting enabled. Interesting, that would indicate there is a problem somewhere with the "std" mapping. It will be good to know when this broke, i.e. please report back when you find the kernel rev that worked for you. -- paul moore linux security @ hp From loulwas at us.ibm.com Tue Feb 27 19:23:49 2007 From: loulwas at us.ibm.com (Loulwa Salem) Date: Tue, 27 Feb 2007 13:23:49 -0600 Subject: [redhat-lspp] Re: different cipso mapping behavior In-Reply-To: <200702271120.17741.paul.moore@hp.com> References: <45E3788F.5060200@us.ibm.com> <200702270940.45898.paul.moore@hp.com> <45E4584A.3030408@us.ibm.com> <200702271120.17741.paul.moore@hp.com> Message-ID: <45E48545.1020902@us.ibm.com> Paul Moore wrote: > On Tuesday, February 27 2007 11:11:54 am Loulwa Salem wrote: > >>Paul Moore wrote: >> > On Monday, February 26 2007 7:17:19 pm Loulwa Salem wrote: >> >>... >> >> > Something odd is happening as based on the packet dump the CIPSO option >> > is 10 >> >>bytes long, which for tag type 1 would indicate a lack of categories yet >>you are using "c2" which should map to CIPSO category "1" based on your DOI >>settings. To further complicate things, assuming I've done my quick math >>correctly the ICMP parameter error is pointing at the CIPSO length field in >>the tag. It's hard to say for certain at this point, but it kinda looks >>like the packet is not being created correctly. >> >> > Please retry with the following CIPSO DOI configuration: >> > >> > # netlabelctl cipsov4 add pass doi:1 tags:1 >> >>The setting above works fine .. that's what I've been using for most of my >>test cases. I am able to log in to the system with above setting enabled. > > > Interesting, that would indicate there is a problem somewhere with the "std" > mapping. It will be good to know when this broke, i.e. please report back > when you find the kernel rev that worked for you. I traced it back to .63 kernel and it is still broken there .. I don't have access to anything prior to that. If someone has access to an older system .. please try it. Paul, were you able to reproduce the problem? I'll keep trying to get the bottom of this meanwhile. - Loulwa From linda.knippers at hp.com Tue Feb 27 19:25:06 2007 From: linda.knippers at hp.com (Linda Knippers) Date: Tue, 27 Feb 2007 14:25:06 -0500 Subject: [redhat-lspp] Re: different cipso mapping behavior In-Reply-To: <45E48545.1020902@us.ibm.com> References: <45E3788F.5060200@us.ibm.com> <200702270940.45898.paul.moore@hp.com> <45E4584A.3030408@us.ibm.com> <200702271120.17741.paul.moore@hp.com> <45E48545.1020902@us.ibm.com> Message-ID: <45E48592.8090408@hp.com> Is there a bugzilla for this? If not, will you please open one? Thanks, -- ljk Loulwa Salem wrote: > Paul Moore wrote: > >> On Tuesday, February 27 2007 11:11:54 am Loulwa Salem wrote: >> >>> Paul Moore wrote: >>> > On Monday, February 26 2007 7:17:19 pm Loulwa Salem wrote: >>> >>> ... >>> >>> > Something odd is happening as based on the packet dump the CIPSO >>> option >>> > is 10 >>> >>> bytes long, which for tag type 1 would indicate a lack of categories yet >>> you are using "c2" which should map to CIPSO category "1" based on >>> your DOI >>> settings. To further complicate things, assuming I've done my quick math >>> correctly the ICMP parameter error is pointing at the CIPSO length >>> field in >>> the tag. It's hard to say for certain at this point, but it kinda looks >>> like the packet is not being created correctly. >>> >>> > Please retry with the following CIPSO DOI configuration: >>> > >>> > # netlabelctl cipsov4 add pass doi:1 tags:1 >>> >>> The setting above works fine .. that's what I've been using for most >>> of my >>> test cases. I am able to log in to the system with above setting >>> enabled. >> >> >> >> Interesting, that would indicate there is a problem somewhere with the >> "std" mapping. It will be good to know when this broke, i.e. please >> report back when you find the kernel rev that worked for you. > > > I traced it back to .63 kernel and it is still broken there .. I don't > have access to anything prior to that. If someone has access to an older > system .. please try it. Paul, were you able to reproduce the problem? > > I'll keep trying to get the bottom of this meanwhile. > > - Loulwa > > > > -- > redhat-lspp mailing list > redhat-lspp at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-lspp From eparis at redhat.com Tue Feb 27 19:29:48 2007 From: eparis at redhat.com (Eric Paris) Date: Tue, 27 Feb 2007 14:29:48 -0500 Subject: [redhat-lspp] Re: different cipso mapping behavior In-Reply-To: <45E48545.1020902@us.ibm.com> References: <45E3788F.5060200@us.ibm.com> <200702270940.45898.paul.moore@hp.com> <45E4584A.3030408@us.ibm.com> <200702271120.17741.paul.moore@hp.com> <45E48545.1020902@us.ibm.com> Message-ID: <1172604588.22087.16.camel@localhost.localdomain> On Tue, 2007-02-27 at 13:23 -0600, Loulwa Salem wrote: > I traced it back to .63 kernel and it is still broken there .. I don't have > access to anything prior to that. If someone has access to an older system .. > please try it. Paul, were you able to reproduce the problem? > > I'll keep trying to get the bottom of this meanwhile. > > - Loulwa What arch? I can publish older LSPP kernels as old as we need. (but I'll run out of quota if I try to do more than 1 or 2 archs) -Eric From paul.moore at hp.com Tue Feb 27 19:33:44 2007 From: paul.moore at hp.com (Paul Moore) Date: Tue, 27 Feb 2007 14:33:44 -0500 Subject: [redhat-lspp] Re: different cipso mapping behavior In-Reply-To: <45E48545.1020902@us.ibm.com> References: <45E3788F.5060200@us.ibm.com> <200702271120.17741.paul.moore@hp.com> <45E48545.1020902@us.ibm.com> Message-ID: <200702271433.45430.paul.moore@hp.com> On Tuesday, February 27 2007 2:23:49 pm Loulwa Salem wrote: > Paul Moore wrote: > > Interesting, that would indicate there is a problem somewhere with the > > "std" mapping. It will be good to know when this broke, i.e. please > > report back when you find the kernel rev that worked for you. > > I traced it back to .63 kernel and it is still broken there .. I don't have > access to anything prior to that. If someone has access to an older system > .. please try it. Okay, thanks for checking. As Linda stated earlier, please file a BZ for this problem and either add me to the CC line or send me the BZ number so I can add myself. > Paul, were you able to reproduce the problem? No, but I have been stuck on something else today. If I don't get to it this afternoon I'll look into it first thing tommorrow. -- paul moore linux security @ hp From loulwas at us.ibm.com Tue Feb 27 19:35:47 2007 From: loulwas at us.ibm.com (Loulwa Salem) Date: Tue, 27 Feb 2007 13:35:47 -0600 Subject: [redhat-lspp] Re: different cipso mapping behavior In-Reply-To: <1172604588.22087.16.camel@localhost.localdomain> References: <45E3788F.5060200@us.ibm.com> <200702270940.45898.paul.moore@hp.com> <45E4584A.3030408@us.ibm.com> <200702271120.17741.paul.moore@hp.com> <45E48545.1020902@us.ibm.com> <1172604588.22087.16.camel@localhost.localdomain> Message-ID: <45E48813.3050604@us.ibm.com> Eric Paris wrote: > On Tue, 2007-02-27 at 13:23 -0600, Loulwa Salem wrote: > >>I traced it back to .63 kernel and it is still broken there .. I don't have >>access to anything prior to that. If someone has access to an older system .. >>please try it. Paul, were you able to reproduce the problem? >> >>I'll keep trying to get the bottom of this meanwhile. >> >>- Loulwa > > > What arch? I can publish older LSPP kernels as old as we need. (but > I'll run out of quota if I try to do more than 1 or 2 archs) > Thanks Eric, ppc kernels would be good. (I tried this on both ppc and x86_64 with same results) - loulwa From paul.moore at hp.com Tue Feb 27 19:36:22 2007 From: paul.moore at hp.com (Paul Moore) Date: Tue, 27 Feb 2007 14:36:22 -0500 Subject: [redhat-lspp] Re: different cipso mapping behavior In-Reply-To: <1172604588.22087.16.camel@localhost.localdomain> References: <45E3788F.5060200@us.ibm.com> <45E48545.1020902@us.ibm.com> <1172604588.22087.16.camel@localhost.localdomain> Message-ID: <200702271436.22282.paul.moore@hp.com> On Tuesday, February 27 2007 2:29:48 pm Eric Paris wrote: > On Tue, 2007-02-27 at 13:23 -0600, Loulwa Salem wrote: > > I traced it back to .63 kernel and it is still broken there .. I don't > > have access to anything prior to that. If someone has access to an older > > system .. please try it. Paul, were you able to reproduce the problem? > > > > I'll keep trying to get the bottom of this meanwhile. > > > > - Loulwa > > What arch? I can publish older LSPP kernels as old as we need. (but > I'll run out of quota if I try to do more than 1 or 2 archs) Thanks for the offer Eric but since Loulwa can't remember the exact kernel rev where this last worked I think we would end up wasting a lot of time/space trying to track down the change which broke the "std" DOI label translations. If I get stuck I may ask you to spin a few select, older lspp.* kernels but for right now I think we are all set. -- paul moore linux security @ hp From loulwas at us.ibm.com Tue Feb 27 20:11:32 2007 From: loulwas at us.ibm.com (Loulwa Salem) Date: Tue, 27 Feb 2007 14:11:32 -0600 Subject: [redhat-lspp] Re: different cipso mapping behavior In-Reply-To: <45E48592.8090408@hp.com> References: <45E3788F.5060200@us.ibm.com> <200702270940.45898.paul.moore@hp.com> <45E4584A.3030408@us.ibm.com> <200702271120.17741.paul.moore@hp.com> <45E48545.1020902@us.ibm.com> <45E48592.8090408@hp.com> Message-ID: <45E49074.7020401@us.ibm.com> Linda Knippers wrote: > Is there a bugzilla for this? If not, will you please open one? > RedHat bugzilla was created # 230255 (copied Linda, Irena, and Paul on it) - Loulwa From paul.moore at hp.com Tue Feb 27 21:09:00 2007 From: paul.moore at hp.com (Paul Moore) Date: Tue, 27 Feb 2007 16:09:00 -0500 Subject: [redhat-lspp] Re: different cipso mapping behavior In-Reply-To: <45E49074.7020401@us.ibm.com> References: <45E3788F.5060200@us.ibm.com> <45E48592.8090408@hp.com> <45E49074.7020401@us.ibm.com> Message-ID: <200702271609.00788.paul.moore@hp.com> On Tuesday, February 27 2007 3:11:32 pm Loulwa Salem wrote: > Linda Knippers wrote: > > Is there a bugzilla for this? If not, will you please open one? > > RedHat bugzilla was created # 230255 > (copied Linda, Irena, and Paul on it) Thank you. -- paul moore linux security @ hp From paul.moore at hp.com Wed Feb 28 00:08:40 2007 From: paul.moore at hp.com (Paul Moore) Date: Tue, 27 Feb 2007 19:08:40 -0500 Subject: [redhat-lspp] different cipso mapping behavior In-Reply-To: <45E3788F.5060200@us.ibm.com> References: <45E3788F.5060200@us.ibm.com> Message-ID: <200702271908.41328.paul.moore@hp.com> On Monday, February 26 2007 7:17:19 pm Loulwa Salem wrote: > Hi Paul, > After the meeting, I went back to try some cipso tests and noticed the > following behavior that didn't use to happen before .. > I am on the latest RHEL drop with the .65 kernel, latest policy .38, and > netlabel_tools-0.17-9.el5 > > I was trying to test the cipso mappings and that a connection is > granted/denied correctly between two systems when mappings are in place. > > Here is what I had a problem with .. > > I set up a system with following rules > netlabelctl cipsov4 add std doi:1 tags:1 levels:2=1 categories:2=1 > netlabelctl map del default > netlabelctl map add default protocol:cipsov4,1 > > Now I try to log in (note I already have a session on the system and I use > that one to log in, so its coming through localhost) > ssh -l testuser/user_r/s2:c2-s2:c2 localhost > > The above command hangs .. Looking at the output of tcpdump (tcpdump -v -i > lo) I see an ICMP error (output at end of this message). I also checked, > and there were no relevant audit records or anything useful in > /var/log/messages or /var/log/secure. For those of you not following the RHEL BZ entry for this problem: *** I should have seen this sooner, but I was thrown off by the "ssh -l testuser/user_r/s2:c2-s2:c2 localhost" command line syntax ... this is not a bug, this is the correct behavior. By configuring a "std" CIPSO DOI with a _only_ level mapping of "2=1" that CIPSO DOI will only allow traffic to be sent when the domain sending the packet has an effective sensitivity level of "s2". The reason for this is that the CIPSO DOI only has a valid level mapping for "s2". The same logic applies to categories. If you were to try to run any network application using the default effective sensitivity label of "s0" then you should not be able to generate network traffic because you have not defined a valid sensitivity label mapping. The fact that network traffic was generated at all (see the packet trace) instead of the socket failing to be created is a side effect of a known bug which has already been patched in the 2.6.19-stable kernels and 2.6.20. Another BZ was entered on January 5th, 2007 to track this other problem (BZ #221648). *** -- paul moore linux security @ hp From loulwas at us.ibm.com Wed Feb 28 16:34:11 2007 From: loulwas at us.ibm.com (Loulwa Salem) Date: Wed, 28 Feb 2007 10:34:11 -0600 Subject: [redhat-lspp] LSPP Development Telecon 02/26/2007 Minutes Message-ID: <45E5AF03.40705@us.ibm.com> 02/26/2007 lspp Meeting Minutes: =============================== Attendees Robin Redden (IBM) - RR Kris Wilson (IBM) - KEW Loulwa Salem (IBM) - LS Debora Velarde (IBM) - DV Joy Latten (IBM) - JL Kylene J Hall (IBM) - KH Irina Boverman (Red Hat) - IB Steve Grubb (Red Hat) - SG Dan Walsh (Red Hat) - DW Eric Paris (Red Hat) - EP Lisa Smith (HP) - LMS Linda Knippers (HP) - LK Amy Griffis (HP) - AG Matt Anderson (HP) - MA Paul Moore (HP) - PM Klaus Weidner (Atsec) - KW Chad Hanson (TCS) - CH Joe Nall - JN Agenda: Agenda and Meeting Formats Bug Discussion Around the Room RHEL 5+ Packages: kernel-2.6.18-8.el5.lspp.65 kernel-devel-2.6.18-8.el5.lspp.65 kernel-doc-2.6.18-8.el5.lspp.65 mcstrans-0.2.3-1.el5 selinux-policy-2.4.6-38.el5 selinux-policy-devel-2.4.6-38.el5 selinux-policy-mls-2.4.6-38.el5 selinux-policy-strict-2.4.6-38.el5 selinux-policy-targeted-2.4.6-38.el5 audit vixie-cron LS: George is still out for a family emergency. We are not sure when he'll be back. If there is anything urgent you need from him, please let us know and we'll try to relay it to him somehow. Ok, I saw there is a .66 kernel and Steve saw a panic in that. SG: yeah, I got a panic as I was rebooting. It may be related to something new that we added in this build, I remember people wanting to get object of signals, maybe there is a lock being held too long there. I don't think anyone reproduced it. Eric was able to crash it in a different way. EP: do we have debug stuff turned on? SG: We talked about that and decided to turn debug option back on. So the next few kernels are likely to have debug turned on to catch bugs more easily. I think there is .67 kernel that will be out shortly. same kernel with debug turned on. JL: do we have to be doing anything in particular to hit the panic you saw? EP: I was loading 2 audit rules, one file watch and watching a program, I am not sure what caused it yet JL: so we can run some tests on this kernel and try it SG: if .67 kernel is out of the build system, we can push it out and would be better to test against it. if you run a suite of tests, you can run it with that to track memory corruption and leaks and to flush out bugs that we wouldn't normally catch. JL: so we should be testing on .67 kernel. SG: yes EP: new panic mean there is new bug that's not on the list. You'll get it next week LS: oh .. sounds great SG: this week I think I'll get time to consolidate all lspp pieces to put them in lspp repository. ID Alias Sev Pri Plt Assignee Status Resolution Summary 218386 nor nor pow eparis at redhat.com ASSI LSPP: labeled ipsec does not work over loopback LS: Joy you were going to do stress test and send patch to ipsec_tools. Any progress on that? JL: I did, everything was great until I noticed something that shouldn't be happening. Usually I test with ESP since you can do authentication with that as well. This time I did a test to make it use ESP and AH protocols in policy to create both of those. This was regular labeled ipsec, and it was creating double amount of SAs. It only does this when I specify both protocols. if I specify one, it works ok. I am tied up with another task until thursday morning then I'll look into this. 223918 nor nor All eparis at redhat.com ASSI LSPP: audit logs bogus obj label in some PATH records LS: Eric said this fix was in .65 kernel. Amy opened it .. has it been verified anyone? EP: Yes, it's in there, and I'd like to hear from HP. AG: have not verified since I've been out on vacation. I'll test it in lspp kernel and verify LS: great, thanks Amy 223919 nor nor All eparis at redhat.com ASSI LSPP: audit does not log obj label when opening an existi... LS: This also was opened by Amy.. do we have status on this one? EP: same deal as the one above. AG: Ok, I'll check both. 225328 nor nor All eparis at redhat.com ASSI LSPP: ipsec drops first packet when using IKE daemon LS: Joy, what's the status on that one. You were talking about trying the upstream kernel.. did you get chance to do that? JL: I tested in .65 kernel. so far no problems. I was testing in ipv4, and still need to try ipv6. I'll start some stress tests tonight. I tested regular and labeled ipsec in ipv4, with loopback also and so far all looks pretty good. ipv6 remains, I'll do that with .67 kernel and see how that works. It's been looking pretty good otherwise. 228366 nor nor All eparis at redhat.com ASSI LSPP: audit does not log obj label for signal recipient LS: we have patch in .65 anyone verified it? EP: this particular one was not in .65. It shows up in .66 and .67, and might be the cause of panic LK: I just loaded .67 kernel and it panic-ed. I loaded a watch and it panic-ed. SG: I think this is a patch that we still need feedback from Al on. I talked to him last week, he was gonna look at this. I'll ask him again. LS: ok, thanks steve. 228384 nor nor All eparis at redhat.com ASSI LSPP: audit does not log obj label for traced process LS: status on this one? EP: need Al's feedback as well and this one does not have a patch. SG: Al said it should be simple to do. I did not see a patch for it. When I catch up to Al, I'll ask about this patch and see if he got it done. LS: ok, thanks Steve for following up. 228422 med nor All eparis at redhat.com ASSI LSPP: cleanup xfrm_audit_log interface LS: Joy you opened this bug. I think this one you said David Miller posted a patch for. JL: I think .65 kernel did have that patch in it. again, since it was in .65 and I tested it, I think it looks pretty good. I have a question about this one and the bug about ipsec dropping package, these were opened in reference to upstream and lspp kernel, should I be testing both in reference to RH bugzilla EP: I would like to hear all info, but what mainly matters is lspp. SG: if you test the patch and it works ok in lspp, I would re-diff it for current devel kernel and check it quick and send upstream. Even if we have them working on lspp, they need to go upstream. we have lots of bugzillas open and we need their patches to be accepted. JL: this bug was initiated upstream.. SG: we should be covered then. If it was an upstream accepted patch and was back ported, then we are ok JL: so should I look at both EP: in most cases, you want to look at both of them. If you really hammer one and lightly test the other it's ok too JL: in lspp kernel this looks good. 228557 med nor All eparis at redhat.com ASSI LSPP: In labeled ipsec, permissions are checked after del... LS: Eric you were working on a patch for this one; any updates? EP: there is patch in lspp.67 kernel and I still need to send it upstream LS: joy did you open it? JL: yes, I'll test it as soon as I get .67 kernel. After I run stress test we can close them out. EP: don't actually close them, just put comment that you tested and it works. 229094 med nor All eparis at redhat.com ASSI LSPP: audit records for some f*xattr syscalls don't inclu... LS: Looks like there was a patch and linda tested it LK: yes, I tested .65 kernel and it works. LS: should we change status on these bugs? SG: What will happen is Eric will post a patch internally, then the bug will go in our bugzilla system and status will be updated. EP: there are number of these bugs that need to be upstream and we need to keep them on my radar, so we don't want to close them yet.. maybe we can put them in a separate list but that way they stay on our radar. JL: does it help if we can just put more info in the bug. EP: yes, as you test, just update the bug with the results SG: Eric, we can put the bugs in a "need info" state. 229527 med nor All eparis at redhat.com ASSI LSPP: flow cache entries remain valid even after selinux ... LS: Eric opened this. status? EP: This came from venkat and I'll get some testing on it JL: not sure how to test this one, I can send venkat an email to ask him about that EP: if you can test it, I'd appreciate it. JL: I'll send him an email and ask him cause I'm not really sure. 229528 med nor All eparis at redhat.com ASSI LSPP: memory leak in flow cache code LS: Eric, status on this? JL: This is another one I can ask venkat about. I'll ask him how to test it as well EP: might be just a code inspection. JL: I'll ask him. 223532 nor nor All mmaslano at redhat.com ASSI [LSPP] crontab manpages reference older environment variable LS: there is a note that says this should be changed to modified. not sure who needs to change it. SG: Dan put it in his page for people to check it and will try to get it in the lspp repository 226780 nor nor All sgrubb at redhat.com ASSI LSPP: audit of writes to files of bin_t produces no records LS: Steve talked about this last week. There is a fix. SG: I'll try to collect that one up and get it in lspp repo later this week. 228398 med nor s39 tmraz at redhat.com ASSI LSPP: Not able to ssh into the machine with multiple cate... LS: We talked last week that we should be using raw context instead. did Tomas have any time to look at this? SG: I think he split this into a new bug, since it is two problems. The original is mcstrans, he opened another one to fix a problem when the number of categories is too much. I think he has taken a suggestion from the bugzilla and started working on the code. I'll follow up on that and if there is package I'll put it in repo as well IB: it is marked as modified. SG: he changed the state just an hour or so ago LS: do we have the new bug number. IB: 230120 229278 urg nor All tmraz at redhat.com ASSI LSPP: ssh-mls allows a level through that it should not LS: This was raised to urgent and I saw notes back and forth on the bug .. what's the verdict on this one? JL: Dan are you there? I'm not sure what to make of the comments DW: problem is the way we are running sshd. I don't know if it is that critical. JL: is it not considered security if someone s2 is allowed as s3? klaus was mostly concerned with that one. KW: the issue is there, ssh has override capabilities, it is up to sshd to enforce restriction on that. can't expect policy to enforce restrictions. It's a matter of opinion if you want code to be in sshd or a library. I think it would be cleaner if utility function returns the decision, but you can have sshd do the check DW: I think sshd should do it KW: having sshd do it should be appropriate. I think it is up to sshd to make sure it does the right thing. CH: stephen is apposed to having it hard coded KW: I am not sure this is really an mls things. if utility function decides to adjust level, it is not just an mls thing, it might not be appropriate in other cases. I don't have an opinion in where it should be fixed, but stephen's comment is correct that we can't expect this to be rejected by policy DW: this is an issue of labeled network. you are requesting context and if it returns something you don't expect it should deny it. JL that would require knowledge of who the user is though .. right? DW: does ssh make decision or libselinux. libselinux returns something different than what you asked for, then you should deny it. KW: what gets returned is definetely wrong in an mls environment, not sure what classes this covers in general. and it's a bit different from what is expected. I think sshd would need special case to reject that. a simpler case might be more appropriate to not use range at all. so just request lower range, and send that to selinux function. DW: why is network ranged anyway JN: right ..It think it shouldn't be ranged KW: in mls environment you normally want to look at low end. In current operating mode, you could actually use the range, but only restricted to trusted people and it is not necessary to have that capability. DW: how does network get a range in first place JN: coming from sender side KW: on sender you have ssh client and it has clearance range that the socket inherits and ssh uses that range, joy correct me if I'm wrong. JL: yes, it's correct KW: what should happen are enforcement rules and they should look at effective lower level. There are only few tools that look at user clearance like newrole. I think it's easier if you have behavior like cipso where you use low level. however, ipsec is designed to do ranges. JL: would it be better if labeled ipsec would take effective level KW: would be easier in mls environment, so whenever you have policy enforced, the right thing will happen. in this case it is trusted application not restricted by policy JN: I thought we need ssh to have a new domain, but you need it for polyinstantiation KW: yes you do, you can do domain with less privileges. I thin sshd need to stay a trusted application. LS: what's final verdict KW: sshd only uses low level instead of range.. so it can truncate the range. it would also work to have ipsec not use ranges but it's a more invasive change. JL: should we think about it for later on DW: should we do it at a lower range or just have it compare the context you get. KW: .. DW: LK: was chad advocating the no ranges CH: I am torn, the range on ipsec doesn't make sense. it works when you try to transfer user clearance. usually a network is a given label. it could be useful. JN: there are places in our code that we look to see what user clearance are. most time we have other mechanisms to do that. In our case, it's not a single level network, but each connection should be. LK: if we change the behavior, it's better to change it now rather than after evaluation. JN: if we go forward, are we going to use ipsec to deal with mechanism ... JL: are you talking about ipsec over loobpack JN: the loopback is kind of bandaid to me. it is a high overhead way to do local networking. JL: thursday would be my priority to get it 100% working JN: right now you are talking about low latency connection, you get kicked out to daemon. it is really high overhead stuff. I don't think it's a long term solution CH: we want to get those resolved as well, it won't be immediate. we need to resolve this instead of .. LK: is this a topic for developer summit .. JN: if mechanism we have passes clearance, then ipsec should for consistency. something to think about as you think about this problem CH: is it really user credentials or labels on package. traditionally you'll write something on file with label. user has effective label and clearance. so that's part of the issue. JN: I guess I wouldn't change anything at this point. change this in ssh now util we come up with a solution. EP: i think everyone who deal with labeled networking, problem is there is no real solution right now. JL: for now, it's ok that it passes range instead of effective level LK: sounds like sshd would need to do the right thing. LS: who would work on this DW: we will SG: between Dan and Tomas we'll work on having something. LS: great .. thank you 228107 nor nor All twaugh at redhat.com ASSI [LSPP] Labels for labeled printing don't linewrap LS: Matt was still working on it. Any status on this one? MA: the patch is coming along, still having trouble with post script. I have it most of the way, but having a bit of trouble. I need to adjust some values. I am most of the way there, need some final testing. 229673 urg nor All twaugh at redhat.com ASSI [LSPP] cups is overriding mls when querying jobs with lpq... MA: I believe I have patch for that finished off, need a bit more testing, that one should go to RH today, and other one (above) should be done this week as well. 229543 med nor All eparis at redhat.com NEW LSPP: odd avc message LS: opened by Kylie. Stephen Smalley said it was not a bug. Kylie did you get a chance to review and decide about this one. KH: we understand what's going on. klaus and people on other side, said they didn't like behavior KW: I don't really like way it behaves, but it's not a problem JN: what info were you trying to capture from avc message. KW: there was no capture of state SG: problem is inconsistent KW: that requires some explanation. CAPP require an audit record for a relevant action with a success/fail state. and you don't get that in this record. SG: out of curiosity. are you keeping list of things that can be done better for next time KW: I'm not keeping list SG: at some point in next few months, I think it'll be good to keep list of that and discuss those issues LK: need to look at things that were closed as not a bug, since those will indicate confusing issues that can be improved. SG: for example we use killall as way of revoking user, better to have revoke syscall...things that meet certification, but that we can do better. LK: can get feedback from Joe and what things they are working on KW: It is important to hear from people who use this system to see how it meets their needs. For example, polyinstantiation has usability issue, and if we get feedback we can see how it worked SG: polyinstantiation needs some help. I would like to hold a conf call sometime in future 2-3 months from now to talk about things that could have been done better, more usable and things we can improve. KW: we can have something like that at the linux symposium. SG: not be in developer summit .. LS: get it on list to get feedback from others as well SG: yes, later down the road, now people are busy. but definetely want to hold this discussion. and would be open to mail list and people of teleconf. SElinux symposium would be a good start point. FC8 will open soon and we need to start to get things in there, that would be probably around April. 229720 med nor All eparis at redhat.com NEW LSPP: pfkey_spdget does not audit xrfm policy changes LS: Eric opened on 2/22, any status? EP: both (below as well) should have patches in .67 JL: I'll test that kernel and see. 229732 med nor All eparis at redhat.com NEW LSPP: pfkey_delete and xfrm_del_sa audit hook is misplaced. LS: Eric, any status on that one too. EP: same as above 223864 nor nor All sgrubb at redhat.com NEW LSPP: Exceptions to expected audit behavior should be doc... LS: Klaus Weidner was going to modify the guide to add this info. Any status. KW: I added some parts to it, will make sure to complete it. KEW: should we also document 229543 .. KW: yes, I'll add that also 228927 med nor s39 sgrubb at redhat.com NEW LSPP: odd audit argument on some 32 bit syscalls LS: Agreed that this info should also be in the config guide. KW: also documented. LS: should they be closed... KW: this is for th IBM config guide. it is appropriate to say they have been documented, but others need to also document it. LK: I'm making a note of these two LS: Kylie, can you verify that the info added is what you needed KH: I can you verify, but I can't close it on RH IB: you can write a comment in there, and we'll update it. 223840 hig nor All twoerner at redhat.com NEW [LSPP] getfacl fails to correctly display all information... LS: Steve said that acl-2.2.39-2 is built with a fix. Klaus kiwi put a note today asking if there is a .el5 version of the acl package we need to pick up. where do we pick the package from? SG: yes there is one, that should also be in the repo that I'll create. LS: I have a couple of questions to bring up, first is regarding the audit package, should we be picking the latest audit from Steve's page. Last week Steve you said there were few fixes you were going to put in (the -se fix was one we needed), what package version should we have? SG: you need the latest package in the 1.3 tree. LS: I saw a 1.4 package on your page, so we don't need to pick that up SG: no, that has more changes, I've hand picked few bug fixes and been porting them back to 1.3 branch SG: did we talk about oops that joy found two weeks JL: I am so glad you mentioned that (audit_log_task_context). I found it in upstream kernel and didn't see that in lssp kernel. Al was looking at that, but didn't see information about it SG: he put a patch out, but it went to selinux mail list I think. JL: to test that one, I can pull upstream kernel and test. Is it ready for testing? IB: if you know the bug number, let me know and I can add it to this list. JL: Let me try to find it (228409) SG: I can give it to Eric and Irena later if you can't find it. KH: Dan you tried to explain on IRC, why a unix read on shm (read down) would fail. we were getting "fd use constraint". we were confused. DW: you are passing it to file process, and were trying to use it for communication. KH: we are able to use getattr correct though DW: getattr is not passing data. KW: .. DW: maybe it's right error, but fd was not closed on exec. KW: there seems to be perm denied only. in that case it is correct DW: it was shm unix write denial. LS: Any more issue we need to talk about? ok then, we'll adjourn. thanks everybody. From paul.moore at hp.com Wed Feb 28 20:01:31 2007 From: paul.moore at hp.com (Paul Moore) Date: Wed, 28 Feb 2007 15:01:31 -0500 Subject: [redhat-lspp] [PATCH] NetLabel: Verify sensitivity level has a valid CIPSO mapping Message-ID: <20070228200140.491071752@hp.com> An embedded and charset-unspecified text was scrubbed... Name: netlabel-cipso_std_bug URL: