| |||||||||||||
|
| |||||||||||||
Why we should careWhy we should carePosted Aug 17, 2005 21:14 UTC (Wed) by tzafrir (subscriber, #11501)In reply to: Why we should care by kokopelli Parent article: An overview of multilevel security
I hardly see too many hirarchial levels here. Trying to abstract it as multi-level doesn't seem to help much. Unix already has a special super-user and some special cases for "guests".
I also fail to see why the ssh key is more sensetive: the ssh daemon has to be able to read it. Thus it is hard to imagine a system where the super-user (that originally executed the sshd) can't read it.
The implementation of SELinux has created a complex set of rules in parallel of the filesystem. Not a pretty sight. Not very managable.
(Log in to post comments)
Why we should care Posted Aug 17, 2005 22:10 UTC (Wed) by smoogen (subscriber, #97) [Link] I think that Selinux is probably soemthing that a home user really cares about.. the places where it is important are more corporate/enterprise systems. The bank wants the person who does package updates not have access to the credit numbers of customers. The hr people dont want the social security data to be available to people who are not priveledged to it. And while encryption might be used to manage the problem.. it does not seem to the whole solution from what I can get out Schneir's books.
In the case of ssh and sensitivity.. I would say that the sshd daemon would have the priveledge of reading that file, but not have the priveledge of reading your /home/snsr/bank_balance.txt file (in the slight case that a root level exploit was found in ssh)
Why we should care Posted Aug 18, 2005 20:47 UTC (Thu) by tzafrir (subscriber, #11501) [Link] Impossible, as sshd needs to launch the shell account of that user. sshd also needs to read a number of files from the user's home directory for some authentication methods.
Sshd already employs priviliges seperation: the part that interacts with unauthenticated remote users (and is thus in the best position to be attacked) runs in in an unpriviliged chrooted jail and connects with the priviliged part through a socket.
Only that unpriviliged part needs to know the server key, I believe.
Another solution: make the ssh private key readable to the group sshd and add sshd to the group sshd. Sshd then does not need to be root to read that file. and we're still using standard unix permissions.
|
|
||||||||||||