[redhat-lspp] login restriction based on terminal range ..

[Daniel J Walsh]

JANAK DESAI wrote:
> Daniel J Walsh wrote:
>
>> JANAK DESAI wrote:
>>
>>> Hello,
>>>
>>> A few months back I had posed a question on how to prevent a
>>> user from logging on to a terminal with a level that is outside the
>>> terminal's sensitivity label range. Stephen suggested some
>>> alternatives but I don't think we reached any conclusion on the
>>> best way to achieve this. I am quoting below Stephen's email
>>> with possible approaches. I would appreciate if you can share
>>> your thoughts ...
>>>
>>> -Janak
>>>
>>> ------------------------------------------------------------------------------ 
>>>
>>>
>>>> On Thu, 2005-09-08 at 10:21 -0400, Janak Desai wrote
>>>>
>>>>> Yes, true. What I meant to say was, how will login handle
>>>>> single level terminals or multilevel terminals with a range
>>>>> of secret to top secret? How will a user cleared to top secret
>>>>> be prevented from loggin in at unclassified on a terminal
>>>>> marked "secret to top secret"? Does get_ordered_context_list
>>>>> take login terminal into account? Similar situations apply
>>>>> to printing on multilevel print device or backing up to
>>>>> multilevel tape device, right? Maybe I am still stuck on
>>>>> my SecureWare B1 way of thinking.
>>>>
>>>>
>>>> get_ordered_context_list/get_default_context doesn't take the terminal
>>>> into account per se, although it does take the context of the calling
>>>> process into account (the fromcon, which defaults to the result of a
>>>> getcon(3) if left NULL).  Hence, you could run different login 
>>>> processes
>>>> with different ranges, although setup might be a pain.
>>>>
>>>> Another option would be to amend the mls_compute_sid logic so that it
>>>> will fail if the process level falls outside of the original tty 
>>>> range.
>>>> At present, it doesn't take the original tty context into account at
>>>> all; it just sets the level in the returned context to the process
>>>> level, so that login et al relabel the tty to the same level as the 
>>>> user
>>>> session without considering the original level/range on the tty.
>>>>
>>>> Or you could try to catch it upon the actual relabel (setfilecon)
>>>> operation by login et al, by defining a mlsvalidatetrans constraint 
>>>> that
>>>> prohibits the tty from being relabeled outside of its original range.
>>>> Although I'm not sure how you would then deal with the need to restore
>>>> it upon session close.
>>>>
>> We also heard about something similar to this from potential 
>> customers.  We now have
>> get_ordered_context_list_with_level which pam_selinux passes the 
>> level that it retrieves from getseuserbyname.  We could either change 
>> pam or getseuserbyname to get the Minimum/Maximum settings for a 
>> terminal (Machine) and adjust the level appropriately.  How you 
>> determine the Minimum/Maximum and modify the level is another thing.
>>
>>
> I am not comprehending the possible change to getseuserbyname since it 
> doesn't have the tty context. There is also the issue of 
> manual_context(). What happens if 
> getseuserbyname/get_ordered_context_list_with_level somehow filter out 
> the context that falls outside the terminal range and forces the user 
> to manually select the level with which to login? Current pam module 
> is not checking if the manually supplied level falls outside the 
> terminal range. So I think your your suggestion of changing pam seems 
> more doable to me. We can change security_label_tty() in pam_selinux. 
> After getting terminal level with getfilecon(), we can check if the 
> level in usercon falls inside the range of the terminal, and if it 
> doesn't, then return null. pam_sm_open_session can then return an 
> error, instead of silently ignoring the null return from 
> security_label_tty(). Would that work? Is this what you were referring 
> when you said "change pam"?
>
> -Janak
>
OK I misunderstood what you were talking about.  I translated terminal 
into machine in my mind.  I have heard requirements about specifying a 
maximum security level of a machine.   The requirement I believe is to 
set the maximum level of  a machine.  So even if a person had a range up 
to SystemHigh when he logged into a say s2 level machine his range would
be SystemLow-s2 instead of SystemLow-SystemHigh.