On Thu, 2007-12-20 at 19:29 -0800, riley.marquis(a)tcsresearch.org wrote: Maybe more secure from one point of view maybe less secure from another. So please no. Not before we have a way how to login on remotely installed vnc machine. If upstream changes it then yes. sshd doesn't support escape sequences which are currently present in issue.net No. They wouldn't except perhaps the LoginGraceTime change. There is a wheel group by default with root as a member. Nonsense. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb

On Thu, 20 Dec 2007 19:29:29 -0800 (PST) riley.marquis(a)tcsresearch.org wrote: Greetings. There are tradeoffs here. I personally would like to see it continue to be enabled until we can figure out more of the issues around disabling it. ...snipp... I would also say this is a bad idea. We want people to use the tools on the machine, don't we? We should take a look I agree, but many of the things bastille did/does are not useful these days. Disabling rsh/rlogin? Disabling compilers (your point 4 I guess)? Setting more agressive security defaults on some applications? Many of the things it does we should be doing in the packages we ship, not trying to modify after install. Would anyone be interested in culling through and coming up with a list of items we should address that bastille does? Personally, I don't find portsentry usefull anymore. The number of port scans that go on anymore means I don't want to hear about blocking specific IP's. I just want everything except specific services blocked by default. There's nothing preventing someone from submitting packages for fedora however... Might be worth doing. I think the reason it hasn't in the past is that there haven't been good international ways of querying for passwords. With encrypted root and instantX this might be worth looking at. You can already do that with smartcards. Just allowing someone to login with a hardware token seems a bad idea. All someone would need is the usb drive. Not possible for fedora. I don't know if the license is acceptable, but it has a kernel module. Fedora doesnt allow kernel modules. Perhaps it could be added to the livna repo? You bet... thanks for the input... kevin

On Friday 21 December 2007 09:13:21 am Kevin Fenzi wrote: <snip to address only Bastille> Since 2000 or so I, or people I know, have found the Bastille project stalled for a platform that it needed to be evaluated against, on at least three occasions. Pulling it up on rpmfind.net, the last changelog entry reads: * Sun Apr 16 2006 Jay Beale <email redacted> 3.0.9-1.0 - Added support for Fedora Core 5 - Added support for SUSE 10.0 - Added support for Mandrake 10.0, 10.1, 2006... - Added support for OS X Tiger (10.4) - preliminary Usefulness depends upon what you're doing. For instance, Bastille was supported on HP-UX, though I no longer know how well. I've seen one environment where not only were the Berkeley 'r' programs were still used very heavily, but also rusers, in which case the portmapper had to be accessible. Granted, this is the sort of thing that applies mostly to non-GUI, often headless, installs. This is probably not a typical environment for Fedora, but one that definitely does happen, and with some frequency. That would require someone who's running a distro that's pretty old. If I still had a SuSE 10.0 or FC5 box, I'd have already run Bastille in evaluation mode, just to see where it was a couple of years ago. If enough people want to see the information, I'd be willing to load FC5 on a box, on a temporary basis, after the holidays. I could also run it from the source tarball on more recent Fedoras, again in eval mode, just for some comparison data. Be advised that working alone, it could take me a couple of weeks to produce all the data. Time is somewhat limited. I've not looked at the code in some time, so I don't know if I'd have to run it against, say, a minimal, GNOME, and KDE install for each version. Also, not being familiar with the current code, it could be full of security or other bugs. The bz2 tarball is 312 KB. That's a fair amount of Perl, which may not have received a plethora of eyeballs, and I've no idea what (if any) test harnesses may have been used, etc. If there's a lot of demand for the information, hopefully someone will also come forward to split the testing load with me. If not, I can live with that, and run everything by mid-January. Actually, I'd *have* to complete it by then, and I can't offer even a cursory code review. Someone may want to take a look at the requires and provides list for some hints about that. This is down to time issues that are beyond my control. My window runs from 1/2/07 through 1/14/07, inclusive. Sorry, folks, but it's the best I can do. I have to admit that I'm not sanguine about receiving an adequate return on investment from Bastille. The periodic halts in the project could mean a fair commitment of resources to avoid future problems. I've also heard stories from people who were able to run it, but found major problems in the ability of typical end users to use it correctly. Overall quality of code is also a huge unknown. That said, I'm not wedded to my opinion. This is just my two cents. Actual data is always preferable, if the community decides to seriously explore this. Not knowing exactly how to define that, as I don't know the size of this community, I'm making an arbitrary call that if a dozen people ask me to do it, I will. If any one person volunteers to split the load, I'll do it. I should probably look for list archives, and grep around for unique posters, just to get an idea of community size. But not today. Last-minute Christmas shopping is the higher priority. Jingle bells, and best wishes, Greg

On Fri, 4 Jan 2008 17:55:49 -0800 (PST) riley.marquis(a)tcsresearch.org wrote: No worries. ;) Well, as you say, you need to make sure we force the user to make a regular account first, currently thats not being done. You can do a new install and not create a user account. I find root ssh login handy for a number of reasons: - You can have some family member or friend who trusts you to fix their linux install allow your ssh key to login as root, then you never need to know any passwords on their system or have a useless normal account there. - It's nice to be able to do for automated tasks (like say installing a single new package on 20 machines without having to login and sudo on each). I wouldn't be opposed to disabling it if it was possible to re-enable for folks who wanted it and we made sure there was always a way to get in via a user account. We just basically need to make sure everything is in place before doing anything like disabling root logins. Sure, but disabling compiling for all the legit users is a bit like throwing out the baby with the bathwater. kevin

Tomas Hoger wrote: Please note that some installations, like ours, would not configure local accounts at all, whether during Kickstart or manual install. We use network accounts (LDAP), and we use ssh keys installed for root for administration. So please don't say things like "you need to make sure we force the user to make a regular account first", because that is not always the case. Perhaps in a small office/home installation these are good points, but not in larger installs with network authentication. We have dozens and dozens of installs on a network used by researchers and we reinstall often and use network authentication, etc. If you are going to consider this sort of thing, please make sure there is a switch somewhere so it doesn't break large site installations. Thanks very much. -- David Pullman Systems Administrator Manufacturing Engineering Laboratory National Institute of Standards & Technology Mail Stop 8203 100 Bureau Drive Gaithersburg, MD 20899-8203 Tel: (301) 975-5385 Fax: (301) 926-3842 E-mail: david.pullman(a)nist.gov

On Jan 10, 2008 10:26 PM, Ville Skyttä <ville.skytta(a)iki.fi&gt; wrote: What about (supposing I know the password of non-root user 'foo', and assuming that 'foo' can sudo yum): [hacker@tooeasy]$ rpm -q --scripts hacker_pkg.rpm postinstall scriptlet (using /bin/sh): rm -rf / exit 0 [hacker@tooeasy]$ scp -p hackers_pkg.rpm foo@host: [hacker@tooeasy]$ ssh -t foo@host sudo yum localinstall --nogpgcheck ./hackers_pkg.rpm Am I wrong in assuming that yum is not necessarily a safe command to be used with sudo? Or more exactly, that there is no point in blocking root ssh logins if you're going to let a user that can login remotely use sudo on yum? Thanks.

On Monday 14 January 2008 11:16:10 am Eric Rannaud wrote: Scary. At first glance it looks like a successful attack. But that wouldn't really be unusual. If your authentication model is based upon passwords, and passwords escape, security is largely out the window. Using a wheel group, etc., can make things tougher, but once you have a bad guy on the system, escalation of privilege attacks are a probability, not a possibility. And they're usually an order of magnitude (at least) easier. Authorization seldom gets the attention that authentication does. That's one reason (but not the major one) that I was asking about whether anyone was thinking about mounting /home noexec. It at least adds an extra authorization layer (though you still have to pay attention to authorization, to prevent attacks in the same vein as the one you've described), in making it harder to do things such as launching a dead-simple (`$0 & $0 &`) forkbomb attack at a critical moment (which can be devastating, depending upon how you have /etc/security/limits.conf set up). The up side is that everyone should be on shadowed passwords, and random bad guys with a user account can't run cracking software against /etc/passwd. The downside is that if you have an undetected bad guy on the system, you will probably lose, in the end. If your attack fails, another will be found. If it's an order of magnitude easier for the bad guy, it's an order of magnitude worse for the admin. If you were 100% confident (hubris) of protecting the sytem before, you should now be 10% confident. Assuming you're going to allow multiple users: If you're going to base everything around passwords, at least read man(1) chage, beware of shoulder-surfing, etc. If you're doing keys, protect your ~/.ssh. If you're doing two-factor, check out your vendor--some fingerprint scanners have been trivially defeated in the past, etc. If thou should lose the Mighty Authentication Battle, thou whilst surely find thyself Groveling Amongst Backups.

On Friday 04 January 2008 05:55:49 pm riley.marquis(a)tcsresearch.org wrote: A bit of data (a means of gathering your own, actually, in the form of a quick-and-dirty bash script) behind my opinion that it's not really worthwhile to restrict gcc, due to a plethora of interpreters. If there are any doubters, please read it over (including relevant man pages) and form your own conclusions about whether it's both useful, and safe to run. I'd like to think that this is a dead issue, but I've not heard back from riley (who raised the point) saying that he buys into the explanation. So, to me, resolution is still in limbo. Much like a bug report, I'd be happier if all concerned parties agreed that it was closed. Plus, I want to clear everyone's minds, while I create my own furor and flamage. I'm all on about noexec mount points, as per my first (original) post earlier today. That's a discussion which will no doubt end in tears. It's been held for years, but IMHO, it's becoming increasingly relevant. #!/bin/bash # Filename: int (interpreters) # Tested on: Fedora 7, RHEL 5.0 # Warnings: # 1) This isn't really the way to write bash. It's highly # simplistic, on the assumption that some who may want to run # it may have zero programming experience, but are (justifiably) # hesitant to run code they've received through a mailing list. # This is my attempt to make it understandable, and more # trustworthy, by reading a few man pages. # 2) This doesn't consider all possible interpreters--only bash, # perl, and python. A typical Fedora install will have several # others. Even a minimal (as defined by installer) RHEL or RHAS # will have others. Ex: awk, though not a shell, is interpreted. # There are also various restricted shells, such as escapes from # from vi, sendmail /usr/sbin/smrsh, etc., which have presented # problems in the past. /etc/shells isn't intended to list # these, and doesn't. # hostname and kernel release uname -nr echo # output a blank line as a spacer # Eliminate self-referential Perl packages via grep. Paste # rpm -q --whatrequires perl | sort -u # into a command line to see a list of Perl software that depends # upon the basic Perl package. rpm -q --whatrequires perl | grep -v '^perl-' | sort -u echo # repeat spacer # Python packages aren't so self-referential, so no grep. But # the list of admin tools many users will need is striking. To # see that list, paste # rpm -q --whatrequires python | grep 'system-config-' | sort -u # into a command line. rpm -q --whatrequires python | sort -u echo # repeat spacer # Report software versions we're using /bin/bash --version | head -n 1 /bin/uname --version | head -n 1 /bin/echo --version | head -n 1 /bin/rpm --version | head -n 1 /bin/grep --version | head -n 1 /bin/sort --version | head -n 1