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

[JANAK DESAI]

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