>>>>> <seifried@seifried.org> writes:> I was looking around for a book specifically on Linux security a week or > two ago, and couldn''t find any. I wanted something Linux specific as > opposed to say O''Reilly''s yellow safe book.There are actually Linux-specific details in Practical; I put some of them there. They are not, however, distribution-specific.> So I started writing one, it is pretty RedHat specific (as the > subject of this email would imply). I would like to get some > feedback before I continue, a.k.a. is it worthwhile/useful?Well, I''d say that about 80% of what you''ll end up with, if you continue, will be a duplication of information found in Practical. There''s very little to Unix security that is specific to Linux. It''s also not at all clear that a Linux-specific security book would be beneficial; without a good understanding of what''s going on any security implementation will fail, and the knowledge for such an understanding is the same be it Linux, FreeBSD, Dec Unix, Solaris, etc. OTOH, your section on RPM is most certainly useful, although it''s a bit sketchy right now. And it''ll be interesting to try and keep your table up-to-date as holes are found and new packages are released. Perhaps you should coordinate the data with one of the various RPM listing web sites or one of the rpm manager tools. -- Grant Taylor - gtaylor@picante.com - http://www.picante.com/~gtaylor/ Where do these people come from? Finger for PGP public key.
I think I may have found a security weakness w/ login in shadow-971001. I
can't imagine this being a large problem if no one has run into it yet,
but I know that's not the way to run security.
It seems that after the user has been authenticated, it makes a call to
setup_uid_gid to change the userID, and (for systems which support
multiple concurrent groups), make a call to initgroups before changing the
UID. if initgroups fails (apparently, EPERM || ENOMEM), setup_uid_gid
returns -1, however is still running as root. Main() does not check a
return from setup_uid_gid, and should continue processing, and execute a
shell, as root.
Tell me I'm missing something...
I appologize for being out of coding long enough to put together a patch
and contact the _right_ people before hand (I'm getting back though),
however if this does in fact need to be patched, it should be as simple as
what's done in su.c from the same package:
Change login.c:960 from
setup_uid_gid(&pwent, is_console);
to:
if (setup_uid_gid(&pwent, is_console))
exit(1);
Sean
At 06:02 PM 7/10/98 -0500, you wrote:>I think I may have found a security weakness w/ login in shadow-971001. I >can't imagine this being a large problem if no one has run into it yet, >but I know that's not the way to run security. >... >I appologize for being out of coding long enough to put together a patch >and contact the _right_ people before hand (I'm getting back though), >however if this does in fact need to be patched, it should be as simple as >what's done in su.c from the same package: >...Did you inform the shadow package maintainer? If you have the source, or even the docs this shouldn't be much of a problem an email address should be included, a simple CC would suffice. Please, everyone, if you have an issue with a package, inform: a) the original author or b) the Linux 'port' maintainer, if not already a. or c) both, if it might affects multiple platforms. In fact, I think it was the maintainer of the shadow package who complained that vendors or users (don't remember) were producing their own patches, yet not informing him of the risk or the patch. If it is the package I think it is then: Author: jfh@tab.com (Julianne F. Haugh) Maintained-by: marekm@piast.t19.ds.pwr.wroc.pl (Marek Michalkiewicz) (according to http://sunsite.unc.edu/pub/Linux/system/admin/shadow.lsm) Current version appears to be 980628 first off...