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

[JANAK DESAI]

Daniel J Walsh wrote:

> 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.
>
Ah, thanks. I will try out the pam change to see if it works as expectd.

-Janak