Date: Sat, 5 Feb 2005 17:24:51 -0600 From: John <john@starfire.mn.org> To: freebsd-questions@freebsd.org Subject: Re: Running top without a shell -- more questions Message-ID: <20050205172451.A49675@starfire.mn.org> In-Reply-To: <971531375.20050206000007@wanadoo.fr>; from atkielski.anthony@wanadoo.fr on Sun, Feb 06, 2005 at 12:00:07AM %2B0100 References: <51563600.20050205125343@wanadoo.fr> <20050205100125.C47038@starfire.mn.org> <971531375.20050206000007@wanadoo.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Feb 06, 2005 at 12:00:07AM +0100, Anthony Atkielski wrote: > John writes: > > J> I am not seeing what you are seeing. I see a login process hanging > J> around with the regular shells, just like you are describing for top. > > It has occurred to me that all my other logins are ssh, so maybe that's > the difference. I don't have telnetd running at all. I logged in directly to a vtty. No telnet, sshd, just me and the keyboard. > J> There's no magic about being a shell. You could write your own. > J> Login isn't treating top any differently than a conventional shell > J> in my system. > > OK. Which by extension means that there aren't any big security > concerns in writing a special-purpose program that replaces the shell > for a specific user, right? For example, if one user is allowed to > execute only a single interactive program and nothing else, I could just > run that program as his shell and not allow him to run a conventional > shell at all, right? If so, it seems like that would be a lot more > secure, provided that the replacement program doesn't have any > shell-like functions (such as user-initiated calls to other programs) > that could be exploited to breach security. Heck, that would mean that > I could even set up a special user that does nothing but allow someone > to play "adventure," no? No, there are HUGE security concerns. The big problem is that many things have shell escapes. Top, as far as I know, does not. > J> Once upon a time, like version 7 Unix, login would simply make an > J> exec-family call to replace itself with the desired "shell" after > J> doing all the setup, ID's changes, and so forth, and that would > J> cause init to spawn a new getty when the wait for that pid returned. > J> It was simple, and it was elegant, it reclaimed the resources used > J> by login (this was in the days of 64k data space + 64k program code > J> space, period), but there was no reliable way to collect logout > J> information, so that hasn't been true in a long, long time. > > Someone gains the terminal back after logout (init?); wouldn't that > program be able to handle logout accounting? init never knew who was logged in. Getty gets the user's name, login gets the password - but that information never goes back to init. > J> What you could do is actually not run login, either. You could > J> modify /etc/ttys to call your own little buffer program. You > J> do NOT want to change /etc/ttys to run top directly, because it > J> would be running as root, and top has a built in k (kill) command, > J> so you would not want to have that! > > I prefer to avoid changing any of the standard software; updates become > a nightmare when you have custom mods out there. No, no! I am not suggesting changing the standard software! I'm not saying to change getty or login, just the usual configuration file that controls where the system runs gettys (or xdm, or what have you). This is no more changing "standard software" than making entries in rc.conf. > I've modified login programs on other systems (not UNIX systems), and > they are maintenance and security nightmares, although you can do all > sorts of cool stuff. I'm not suggesting you do so. > Thanks for the other suggestions, though. I'll look them up if I ever > wish to again tread the dangerous path of site modifications to standard > software (right now, I just don't have the time to open that can of > worms, alas!). I'm not suggesting you modify any standard software. I'm not suggestion you run a custom getty for all your logins. I'm just saying that rather than running ANY login softwater at all - just use init to run top instead! Look - if this makes you more comfortable - just turn off logins ENTIRELY on one ttyv. Then use the program I wrote to just run top on the ttyv on which logins are no-longer allowed. You could start it with cron or /etc/rc.d something instead of /etc/ttys. It doesn't matter how it gets started - the point is, NO LOGIN AT ALL is allowed on that terminal - how is that a security risk? You don't have to log in as top or root or anything - no logins - top just runs as the user YOU specify.... -- John Lind john@starfire.MN.ORG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050205172451.A49675>