[redhat-lspp] LSPP Development Telecon 01/29/2007 Minutes

[Ted X Toth]

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
>>     
>
>
>