Weekly Edition
Return to the Press page
| |||||||||||||
|
| |||||||||||||
Latest Linux kernel to control access (vnunet)
The vnunet article looks
at features that will be included in the 2.6 version of the Linux kernel.
"Recent developments to improve task scheduling and the handling of
threads mean that Linux has just about solved the scalability problems that
have prevented many IT departments from using Linux on high-end
hardware. These updates are also set to debut in version 2.6."
(Log in to post comments)
article somewhat lacking in clues Posted Nov 2, 2002 4:57 UTC (Sat) by einstein (subscriber, #2052) [Link] The linux kernel has always controlled access to the system - that's been since day one, nothing new. They mistake the "acl" buzzword for the concept of controlling access...There are other similar clues of cluelessness in the article as well...
Latest Linux kernel to control access (vnunet) Posted Nov 3, 2002 2:02 UTC (Sun) by socket (guest, #43) [Link] I have to agree with the previous poster, the article displayed a lack of understanding on its author's part.My main confusion was at the relationship between the title of this article and the summary. Task scheduling and thread handling *does* help with scalability problems.... but what does that have to do with controlling access? What access is being controlled, and how is it new? ACL patches have been around for quite a while, if I remember correctly, and I'm pretty sure that the hooks for allowing ACLs in the VFS have been there through at least most of 2.4.
Latest Linux kernel to control access (vnunet) Posted Nov 3, 2002 16:18 UTC (Sun) by hazard (guest, #3695) [Link] Moreover, comments regarding lack of security features to restrict processes rights are also untrue. Linux kernel has "capabilities" system since 2.2, however the problem is that it was never really adopted by major distributions, mostly due to a lack of a way to force restrictions by marking them in the executable file or via attributes of the file system (right now the process has to release rights itself). However, some distributions DO use it, like Astaro Linux.
Latest Linux kernel to control access (vnunet) Posted Nov 3, 2002 20:32 UTC (Sun) by XulChris (guest, #7436) [Link] This article is very timely. He says that one major problem with linux is that it has SUID root files such as ssh. Please reference this thread today on the linux kernel mailing list here. It looks like linux 2.6 will have new file system capabilities which will eliminate the need for any suid root files! So the only drawback to 2.6 that the author mentions is already being worked on.
Latest Linux kernel to control access (vnunet) Posted Nov 4, 2002 0:52 UTC (Mon) by Ross (subscriber, #4065) [Link] Ssh has no need to be suid root. I always remove the suid bit.Actually, my firewall has zero suid or sgid applications. I can't use su, but that's about the only problem I've had. (SSH needs to run as root to bind to a low port number to
Response to Ross Posted Nov 4, 2002 2:05 UTC (Mon) by einstein (subscriber, #2052) [Link] Ross wrote:> SSH needs to run as root to bind to a low port number to hmm, I thought it needed to start as root in order to bind to port 22. vis a vis the "why not rsh" question, why send passwords and/or data in the clear with rsh, when you could have everything encrypted via ssh?
Response to Ross Posted Nov 4, 2002 15:17 UTC (Mon) by NAR (subscriber, #1313) [Link] You mixed up ssh and sshd. Of course, sshd has to bind to port 22, but ssh also has to bind to a port below 1024 in order to enable RSA authentication (or something like this). It will work without the suid bit, but some features will be unavailable to the user.
Response to Ross Posted Nov 7, 2002 9:28 UTC (Thu) by Peter (guest, #1127) [Link] Of course, sshd has to bind to port 22, but ssh also has to bind to a port below 1024 in order to enable RSA authentication (or something like this). Close. It is to enable host-based RSA authentication. And most people don't need it. Here's what it does: With normal RSA authentication, you list some public keys in your .ssh/authorized_keys file. Anyone with access to any of the corresponding private keys (often .ssh/id_* or .ssh/identity) can log in as you without a password. The authentication is in the fact that the user can prove he knows the private key. With host-based RSA auth, you have a file in your home directory called .rhosts or .shosts listing the accounts allowed to log in as you - which usernames on which computers. For this to work securely, the server has to trust the client not to lie. Rather than relying on the client's ability to bind a low port (as rsh does), the server stores the client's machine-wide public key (in /etc/ssh/ssh_known_hosts or .ssh/known_hosts) and the client uses the corresponding private key (/etc/ssh/ssh_host*_key) to assert that it can be trusted to identify itself and the username. For obvious reasons, reading the system-wide private key requires setuid root (or some other way of restricting access). As I said, it is usually a lot easier / better just to use per-user RSA authentication, in which case the client does not need to be setuid. One exception would be, if you have NFS-mounted home directories, you don't want people putting private keys on them, so you might have a system-wide /etc/ssh/shosts.equiv that lets a whole group of computers trust each other for authentication. (Even then there are some good reasons not to do this....)
Response to Ross Posted Nov 4, 2002 20:01 UTC (Mon) by Ross (subscriber, #4065) [Link] I wouldn't suggest that anyone use rsh... I don't anymore. What I meantwas that if they insist on using that protocol, why can't they actually use rsh command rather than ssh command in compatability mode?
|
|
||||||||||||