Date: Mon, 16 Nov 1998 12:38:11 -0600 From: William McVey <wam@sa.fedex.com> To: Terry Lambert <tlambert@primenet.com> Cc: hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? Message-ID: <199811161838.MAA25024@s07.sa.fedex.com>
next in thread | raw e-mail | index | archive | help
[ This is a fairly long reply. The last paragraph has some
info related to xterm's need for root permissions of possible
interest. ]
I'm in favor of the proposed change to allow some group (for discussion
sake, lets call it group 'shadow') read permission to the shadow file.
Unfortunatly, it's not enough. The getpwnam (and family) needs to be
modified to base their access method on access to the file as opposed to
a "root or not-root" check. The routine __initdb() in
/usr/src/lib/libc/gen/getpwent.c seems to be the place to make the change...
(I code the propose "patch" very quickly, it should defintly be reviewed).
before:
p = (geteuid()) ? _PATH_MP_DB : _PATH_SMP_DB;
_pw_db = dbopen(p, O_RDONLY, 0, DB_HASH, NULL);
if (_pw_db) {
[code]
after:
if((DB *)0 == (_pw_db=dbopen(_PATH_SMP_DB, O_RDONLY, 0, DB_HASH, NULL))) {
_pw_db = dbopen(_PATH_MP_DB, O_RDONLY, 0, DB_HASH, NULL);
}
if ((DB *)0 ==_pw_db) {
[code]
Terry Lambert wrote:
>There are several holes in the theory. The number one hole is
>that if I'm trusting you to read the engrpted passwords, I'm
>trusting you to not run "crack" (or whatever) against the
>password file.
True, but root passwords are of course secure enough to withstand
crack (they are on my boxes at least).
>Basically, DES is insecure enough tese days that
>if I trust you with read access, I'm effectively trusting you
>with the root password (if you had access to the EFF hardware,
>you could obtain root in less than an hour).
This logic is flawed. For one, there is no requirement that
encrypted passwords be "encrypted" with DES. MD5 hashing has been
an option on FreeBSD for a long time. Even assuming DES hashing
is enabled on a box, it's important to remember that DES hashing
is not the same as DES encryption. The interative nature of DES
hashing (even the lowest security of crypt() has 25 iterations of
DES encryption) means that it's a more time consuming to break
the hash than to break a DES encrypted file. Extended DES hashing
can use up to 16 million iterations of DES encryption to form the
hash. Saying that possesion of EFF hardware makes encrypted password
entries crackable within an hour is assuming a level of security
which is not universal.
>I think it's a bad idea to spread this trust around like this.
Trust is still being placed into the root-owned xlockmore program.
There is no denying that. If xlockmore were compromised, it could
still be trojaned to store typed in user (and possibly even root)
passwords as clear text to a file or mail message. That's why it
still important for xlock to still be owned and writable by only
root.
>Second, if I trust a program to read the file, but not to write
>it, I'm saying I have less trust in the program than I would hold
>out for "root". This is ridiculous, since I'm implicitly trusting
>the program to not have a hidden option to enumerate the shadow
>password database contents, and I'm also entrusting it to not be
>a trojan that, when passwords are successfully validated, the
>account/password information gets sent someplace.
Your implicit trust is that the program isn't intentionally malicious.
That's different than trusting that the program doesn't have buffer
overflows, race conditions, or other programming errors which might
be abused. I have a higher degree of trust that xlock isn't
intentionally malicious than I do that xlock (or any of it's
underlying libraries) doesn't have bugs that might be exploited.
When faced with this kind of partial trust, I'm inclined to want to give
it only limited permissions.
>Basically, if I'm in for a penny, I'm in for a pound, and relying
>on obscurity and spreading the wealth around are both bad security
>risks.
One of the basic tenants of unix security is to minimize the
permissions needed to accomplish a task. Let's say xlock has a
race condition that would allow it to create new files. With setuid
root permissions (or any other user for that matter), a new .rhosts
(or perhaps a new .login or .profile) file could be created leading
directly to a compromise of that account. With setgid permissions,
the worse that could happen would be the creation of a file owned
by the original user and grouped to the 'shadow' group. The user
would have a hard time exploiting this since he can't make it setgid
since he is presumably not in the 'shadow' group (if he were, this
would all be moot anyway). Granted, race conditions and buffer overflows
are programming bugs which should be eliminated out of all programs
(especially those with privileges), but the unix filesystem and permission
model allows us to mitigate a lot of those risks by restricting access
privileges to a narrowly defined set of operations.
>> Another thing that would be nice would be to give certain user id's
>> the ability to listen on low-numbered sockets without giving the rest
>> of the users that ability.
>
>SCO ODT had this "feature". SVR4 also has this "feature". It's
>effectively the same thing as VMS (or NT) installed images, where
>the image itself conveys permission to do things.
I remember reading a research paper which had added a group per
privileged system call. The permission check in the system calls
were modified to check for membership in that system call's group as
well being root. I think the code to do this was applied against one
of the free BSDs of the time (FreeBSD, NetBSD, OpenBSD, perhaps even
BSD4.4). I tried try and locate a copy of it but couldn't find it
quickly...
>> * xterm (suid root for utmp access)
>
> Yeah, well, this is just bogus because of the way credentials
> are handled in FreeBSD. It's the same reason we can't have
> per-user instead of per-machine SAMBA credeintions: there's
> no explicit session manager to act as credential holder, and
> to which programs can proxy requests.
For years xterm has had support for ptyd, a small daemon program
written by Kevin Braunsdorf which would hand out ptys in a secure
fashion. It can be found at: ftp://ftp.physics.purdue.edu/pundits/
-- William
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811161838.MAA25024>