From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1LOyyb-0000Fy-Fe for garchives@archives.gentoo.org; Mon, 19 Jan 2009 18:35:58 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 543ECE041F; Mon, 19 Jan 2009 18:35:55 +0000 (UTC) Received: from mail-bw0-f17.google.com (mail-bw0-f17.google.com [209.85.218.17]) by pigeon.gentoo.org (Postfix) with ESMTP id A550FE041F for ; Mon, 19 Jan 2009 18:35:54 +0000 (UTC) Received: by bwz10 with SMTP id 10so1399376bwz.14 for ; Mon, 19 Jan 2009 10:35:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=cGt3rZFi1g/hnTHvOH76jnUVAn3bZgC+9XVEEEryaxo=; b=AyWodTDmZQmZMJLlT9bgY0D5CUyFCpKF8estRgpO7JhWrnkRJwY1/GYSiGnSGdRPYH +Q13nWA9gB8z41nOHZTVBi4r3Bv4qwGMC7BqsZQGtXBp+teQ3MCtI2I+4/r1DfhEwYPG njSyYbLG45D9n9MBu1GdJan9owjmkd5jO7JcU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=s3XIku1eUj8e1QoqhXRKUcjE3c3DjOz7HV/uVqjn2gEOayJ7wj3tIVjm0OLya4XaKt AY+UiYsut9OqgUEtHASeER1Hq1isaWmifaoPuKrCZmK+iTamXg6eNl0mfpjLk9M9u54m cdPKsL03LWRHVL/CjG8yARbZaNyaVtWQYBbjc= Received: by 10.181.222.5 with SMTP id z5mr2157596bkq.170.1232389982091; Mon, 19 Jan 2009 10:33:02 -0800 (PST) Received: by 10.180.208.18 with HTTP; Mon, 19 Jan 2009 10:33:02 -0800 (PST) Message-ID: <49bf44f10901191033j5ff29d9dv207d76d3e40c3f65@mail.gmail.com> Date: Mon, 19 Jan 2009 10:33:02 -0800 From: Grant To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Reconciling users and services In-Reply-To: <200901182309.48081.alan.mckinnon@gmail.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200901180954.51906.alan.mckinnon@gmail.com> <49bf44f10901181012i766a1a3fmf0a18066c794bcae@mail.gmail.com> <200901182309.48081.alan.mckinnon@gmail.com> X-Archives-Salt: 95146961-f7d9-4a87-be90-b95956388c60 X-Archives-Hash: 605b761a7effd119e50b67dc221435a1 >> >> I have some users on a system and some services. How can I make sure >> >> only certain users can log into certain services? Do I need to >> >> explicitly define which users can log into each service? Are there >> >> different types of users so that some can only log into certain >> >> services? >> >> >> >> For example, I know any user that has their shell set to /bin/nologin >> >> can't log into a shell. How can I check on users' shell settings? >> >> >> >> - Grant >> > >> > To do this you configure each service separately (there is no central >> > registry-type thing for this). You don't say what "services" you are >> > interested in, so I have to make some assumptions. >> > >> > apache, samba, ftp servers, all have their own authentication methods. >> > You have to research what methods they provide, and choose which is most >> > appropriate. For instance, Samba can auth against kerberos/ldap or using >> > a local smbpasswd file. For a specific user to be able to access >> > something via samba, you ensure they have an entry in AD or a line in >> > smbpasswd. >> > >> > For more simple local services, you can use user and group permissions. I >> > have to restrict cron and wget at work, I find the easiest way is to: >> > chown root:trusted /usr/bin/wget >> > chown root:trusted /usr/bin/crontab >> > users authorized to use wget/cron must then be put in the trusted group. >> > >> > cron has it's cron.allow and cron.deny files that you can also use. >> > >> > sshd has config options to limit who can do what in sshd_config. >> > >> > If you post back with more specifics about what you want to achieve, we >> > can assist you better. >> >> As far as open ports, most of my systems only run sshd and cupsd. >> I've set AllowUsers in sshd_config to only allow my own non-root user >> to log in, and I've locked down cupsd.conf. However, one of my >> systems runs things like apache2, postfix, courier-imap, saslauthd, >> mysql, and sshd. I set them up to be secure when I installed them, >> but I wonder about the different users on my system (none of them with >> shell access) and their access to the different services. Should I go >> through each of these services and set up something similar to >> AllowUsers so that only certain users have access to certain services? Thanks a lot for going over this with me. More below.... > Yes, that is the way of it. You really so need to attack each service > individually and set it up appropriately. > > You can limit your exposure by removing most of those users from /etc/passwd > if all services they need use virtual users. For instance, if people only > need a pop mailbox, make them virtual users defined only in your pop server. > > Whether you can do this universally depends very much on your exact needs and > how you like to set things up. Unix daemons are extremely flexible, this is > their strength and weakness. Strength because you can always get exactly what > you want somehow, weakness because there's no standard howto recipe > >> On the subject of users, there are a lot of users in /etc/passwd, >> although most of them have /bin/false or /sbin/nologin. There are 8 >> users who have a different shell defined. The first 3 are fine: >> >> root /bin/bash >> user /bin/bash > > What is this? Looks like some generic catch-all account. That's usually a > recipe for disaster as it's the kind of thing that gets forgotten. That OK, it's me. > It's definitely not a standard user for any distro I've ever seen, so why do > you have it? > >> cart /bin/bash >> >> The next 3 are probably fine: >> >> sync /bin/sync >> shutdown /sbin/shutdown >> halt /sbin/halt >> >> But I don't recognize the following 2. Should I userdel them? >> >> operator /bin/bash >> guest /dev/null > > What are they used for? I've just done a huge project to clean up and > centrally manage all users on all my servers (about 100 machines), so I > learned some tricks to find redundant users: > > grep -r /etc/* > look at mailboxes > look in crontabs > ps axu | grep > lsof -u > find / -user -ls > > sift through all these outputs looking for evidence of an account that is > actually used. Again, there's no standard recipe. This kind of audit > absolutely requires eyeballs and a brain OK, I've deleted 'operator' and 'guest'. >> mysql only needs to connect to a daemon running on the same system, >> and I think it does so via a unix socket as opposed to tcp. I can see >> from netstat that /var/run/mysqld/mysqld.sock is connected, there is >> no mention of a tcp mysql connection, and nmap does not show a mysql >> port to be open. Is there anything else I should do as far as locking >> down mysql? I'm the only one with shell access to the system. > > mysql should be running as a non-root user (probably mysql) and for what you > use, should be listening on localhost only. If you need to connect over the How can I check to make sure mysql is only listening to localhost? It doesn't show up with nmap. - Grant > network, the usual technique is to allow access only to specified users and > only to specified machines. The latter can be done with > > a. The service's own config (many services support this) > b. hosts.[allow|deny] is the service is built against libwrap > c. iptables if nothing else suffices (this is hard to manage so it's a last > resort) > >> I would appreciate any other security advice regarding any of the >> above-mentioned services.