headers
Simon J. Gerraty | 3 Sep 2005 23:34

Re: security/10206 - proposed solution (concept)

>The current version has the following options when setting a policy:
>minlen, maxlen, upper, lower, digits, punct.

I've implemented something similar in another OS...

>An example entry in /etc/passwd.conf for at least 8 character passwords
>combining both upper/lower case and digits can be:

>policy:
>  minlen = 8
>  upper = yes
>  lower = yes
>  digits = yes

Actually I think this is a bad idea - it actually helps an attacker narrow
the keyspace.  The appoach I took was to document the different character 
sets that the full ascii space is devided into, and then have a setting that
states how many of those sets have to be used.  No detail of which ones
are used so an attacker still has to consider them all.

I also have another mode where the restiction simply states how many times
the passwd must change character set - but this can be met using only two
sets and toggling between then - but again an attacker cannot deduce from
the config that the keyspace has been narrowed.

Apart from anything else, keeping the full keyspace is good when 
trying to meet requirements like FIPS 140 or the 
Common Criteria FIA_SOS family.

--sjg
(Continue reading)

Permalink | Reply | 1169 comments |
headers
Elad Efrat | 3 Sep 2005 23:35
Picon

Re: security/10206 - proposed solution (concept)

Simon J. Gerraty wrote:

> I've implemented something similar in another OS...

You forgot to attach it. ;)

-e.

--

-- 
Elad Efrat
PGP Key ID: 0x666EB914
Permalink | Reply | 0 comments |
headers
Perry E. Metzger | 10 Sep 2005 20:17
Gravatar

etc/kerberosV unneeded?


Our krb5.conf goes in /etc, not into /etc/kerberosV/.

Does the /etc/kerberosV directory serve any purpose? Should we delete
it from the standard mtree?

(Also, does /etc/kerberosIV still serve any purpose at this point?)

Perry
Permalink | Reply | 3 comments |
headers
John Nemeth | 14 Sep 2005 07:29
Picon
Favicon

need for end*ent()?

     I am working on libwrap to remove a reference to getgrnam().
Immediately after the use of getgrnam(), it calls endgrent() (there is
also a call to endpwent()).  I'm considering removing these in order to
reduce possible side effects on applications using the library.
However, I'm wondering if they should be left to ensure database
updates are seen in long running daemons as per this paragraph in the
manpage:

     It is dangerous for long-running programs to keep the file descriptors
     open as the database will become out of date if it is updated while the
     program is running.

Does anybody else have any thoughts on this issue?
Permalink | Reply | 2 comments |
headers
Hubert Feyrer | 14 Sep 2005 07:45
Picon
Favicon

Re: need for end*ent()?

On Tue, 13 Sep 2005, John Nemeth wrote:
>     I am working on libwrap to remove a reference to getgrnam().
> Immediately after the use of getgrnam(), it calls endgrent() (there is
> also a call to endpwent()).  I'm considering removing these in order to
> reduce possible side effects on applications using the library.
> However, I'm wondering if they should be left to ensure database
> updates are seen in long running daemons as per this paragraph in the
> manpage:
>
>     It is dangerous for long-running programs to keep the file descriptors
>     open as the database will become out of date if it is updated while the
>     program is running.
>
> Does anybody else have any thoughts on this issue?

The calls exist and are being used (properly) for the stated reason.
Why would you want to remove them?

  - Hubert
Permalink | Reply | 0 comments |
headers
John Nemeth | 14 Sep 2005 09:07
Picon
Favicon

Re: need for end*ent()?

On Dec 30,  7:52pm, Hubert Feyrer wrote:
} On Tue, 13 Sep 2005, John Nemeth wrote:
} >     I am working on libwrap to remove a reference to getgrnam().
} > Immediately after the use of getgrnam(), it calls endgrent() (there is
} > also a call to endpwent()).  I'm considering removing these in order to
} > reduce possible side effects on applications using the library.
} > However, I'm wondering if they should be left to ensure database
} > updates are seen in long running daemons as per this paragraph in the
} > manpage:
} >
} >     It is dangerous for long-running programs to keep the file descriptors
} >     open as the database will become out of date if it is updated while the
} >     program is running.
} >
} > Does anybody else have any thoughts on this issue?
} 
} The calls exist and are being used (properly) for the stated reason.
} Why would you want to remove them?

     Because if the application happens to iterating a database by
using getgrent() or getpwent() at the time it makes a call to libwrap I
wouldn't want its pointer to be reset.  I have no idea why an
application would do this.  However, I don't think it is up to me or
necessarily up to any particular library to make this choice for it.

}-- End of excerpt from Hubert Feyrer
Permalink | Reply | 1 comment |
headers
Steven M. Bellovin | 14 Sep 2005 09:51

Re: need for end*ent()?

In message <200509140707.j8E77lfP011272 <at> vtn1.victoria.tc.ca>, John Nemeth write
s:
>On Dec 30,  7:52pm, Hubert Feyrer wrote:
>} On Tue, 13 Sep 2005, John Nemeth wrote:
>} >     I am working on libwrap to remove a reference to getgrnam().
>} > Immediately after the use of getgrnam(), it calls endgrent() (there is
>} > also a call to endpwent()).  I'm considering removing these in order to
>} > reduce possible side effects on applications using the library.
>} > However, I'm wondering if they should be left to ensure database
>} > updates are seen in long running daemons as per this paragraph in the
>} > manpage:
>} >
>} >     It is dangerous for long-running programs to keep the file descriptors
>} >     open as the database will become out of date if it is updated while th
>e
>} >     program is running.
>} >
>} > Does anybody else have any thoughts on this issue?
>} 
>} The calls exist and are being used (properly) for the stated reason.
>} Why would you want to remove them?
>
>     Because if the application happens to iterating a database by
>using getgrent() or getpwent() at the time it makes a call to libwrap I
>wouldn't want its pointer to be reset.  I have no idea why an
>application would do this.  However, I don't think it is up to me or
>necessarily up to any particular library to make this choice for it.
>
If that's the case, you're already in trouble, I think -- won't 
getpwnam_r() reset the pointer?  The man page doesn't say (and I
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Nemeth | 14 Sep 2005 10:10
Picon
Favicon

Re: need for end*ent()?

On Feb 3, 10:26pm, "Steven M. Bellovin" wrote:
} In message <200509140707.j8E77lfP011272 <at> vtn1.victoria.tc.ca>, John Nemeth writes:
} >On Dec 30,  7:52pm, Hubert Feyrer wrote:
} >} On Tue, 13 Sep 2005, John Nemeth wrote:
} >} >     I am working on libwrap to remove a reference to getgrnam().
} >} > Immediately after the use of getgrnam(), it calls endgrent() (there is
} >} > also a call to endpwent()).  I'm considering removing these in order to
} >} > reduce possible side effects on applications using the library.
} >} > However, I'm wondering if they should be left to ensure database
} >} > updates are seen in long running daemons as per this paragraph in the
} >} > manpage:
} >} >
} >} >     It is dangerous for long-running programs to keep the file descriptors
} >} >     open as the database will become out of date if it is updated while th
} >e
} >} >     program is running.
} >} >
} >} > Does anybody else have any thoughts on this issue?
} >} 
} >} The calls exist and are being used (properly) for the stated reason.
} >} Why would you want to remove them?
} >
} >     Because if the application happens to iterating a database by
} >using getgrent() or getpwent() at the time it makes a call to libwrap I
} >wouldn't want its pointer to be reset.  I have no idea why an
} >application would do this.  However, I don't think it is up to me or
} >necessarily up to any particular library to make this choice for it.
} 
} If that's the case, you're already in trouble, I think -- won't 
} getpwnam_r() reset the pointer?  The man page doesn't say (and I
(Continue reading)

Permalink | Reply | 4 comments |
headers
Steven M. Bellovin | 14 Sep 2005 10:15

Re: need for end*ent()?

In message <200509140810.j8E8AEcN028511 <at> vtn1.victoria.tc.ca>, John Nemeth write
s:
>On Feb 3, 10:26pm, "Steven M. Bellovin" wrote:
>} In message <200509140707.j8E77lfP011272 <at> vtn1.victoria.tc.ca>, John Nemeth wr
>ites:
>} >On Dec 30,  7:52pm, Hubert Feyrer wrote:
>} >} On Tue, 13 Sep 2005, John Nemeth wrote:
>} >} >     I am working on libwrap to remove a reference to getgrnam().
>} >} > Immediately after the use of getgrnam(), it calls endgrent() (there is
>} >} > also a call to endpwent()).  I'm considering removing these in order to
>} >} > reduce possible side effects on applications using the library.
>} >} > However, I'm wondering if they should be left to ensure database
>} >} > updates are seen in long running daemons as per this paragraph in the
>} >} > manpage:
>} >} >
>} >} >     It is dangerous for long-running programs to keep the file descript
>ors
>} >} >     open as the database will become out of date if it is updated while
> th
>} >e
>} >} >     program is running.
>} >} >
>} >} > Does anybody else have any thoughts on this issue?
>} >} 
>} >} The calls exist and are being used (properly) for the stated reason.
>} >} Why would you want to remove them?
>} >
>} >     Because if the application happens to iterating a database by
>} >using getgrent() or getpwent() at the time it makes a call to libwrap I
>} >wouldn't want its pointer to be reset.  I have no idea why an
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charles M. Hannum | 14 Sep 2005 16:07

OpenSSH key size

There is a talk being presented at MIT today that shows clearly that 1Kb 
public keys can be factored fairly easily on cheap custom hardware.  It is 
long past time for SSH keys to be at least 2Kb by default.
Permalink | Reply | 14 comments |

Gmane