headers
Greg A. Woods; Planix, Inc. | 18 Aug 2008 20:12
Picon
Favicon

Re: BSD Auth


On 18-Aug-08, at 7:50 AM, markucz <at> gmail.com wrote:
>
> Straight to the point: is there a way to use BSD Auth with NetBSD?

One can try porting the BSD Auth code from OpenBSD.  I have not yet  
tried that myself.

> In 4.0 one
> can't do without PAM.

Perhaps not without building yourself from source.  :-)

However I seem to be doing fine without PAM in my netbsd-4 systems.

I use the following settings in my mk.conf (plus there should be some  
changes to some makefiles and to the sets lists, but I haven't got  
around to them yet):

	MKPAM =         no
	USE_PAM =       no

> I've lived happily without it so far. I don't mind
> having it in base, I'm just curious whether it's possible to replace  
> its
> functionality by BSD Auth. I managed to find some code written in  
> 2003 [1],
> and now I'm examining it to see what can be done with it and if it  
> can be
> somehow integrated alongside with PAM.
(Continue reading)

Permalink | Reply | 12 comments |
headers
SODA Noriyuki | 19 Aug 2008 06:23
Picon

Re: BSD Auth

>>>>> On Mon, 18 Aug 2008 14:12:10 -0400,
	"Greg A. Woods; Planix, Inc." <woods <at> planix.ca> said:

> Previous discussions resulted in nothing really and PAM was blasted
> into the tree without taking into account any technical
> considerations.

Such summary is unfair.

From some points of view, PAM is more secure than BSD Auth, and that
was one of reasons why PAM was choosed.

With PAM, password attack can be only done via programs who already
own root privilege.  With BSD auth, anyone can do password attack.
For practical example, "pkgsrc/security/pam-pwauth_suid" implements
restriction that a user can try only his own password.  BSD auth opens
wider window against such attack.

Another reason is that some features like Kerberos credential handling
cannot be implemented by BSD auth.
--

-- 
soda
Permalink | Reply | 9 comments |
headers
Greg A. Woods; Planix, Inc. | 19 Aug 2008 07:33
Picon
Favicon

Re: BSD Auth


On 19-Aug-08, at 12:23 AM, SODA Noriyuki wrote:

>>>>>> On Mon, 18 Aug 2008 14:12:10 -0400,
> 	"Greg A. Woods; Planix, Inc." <woods <at> planix.ca> said:
>
>> Previous discussions resulted in nothing really and PAM was blasted
>> into the tree without taking into account any technical
>> considerations.
>
> Such summary is unfair.

I think it's pretty fair.  No consensus was reached on the contentious  
points

> From some points of view, PAM is more secure than BSD Auth, and that
> was one of reasons why PAM was choosed.

I've never seen any real technical evaluation showing PAM to be more  
secure.

Show me where the evaluation is.

> With PAM, password attack can be only done via programs who already
> own root privilege.  With BSD auth, anyone can do password attack.
> For practical example, "pkgsrc/security/pam-pwauth_suid" implements
> restriction that a user can try only his own password.  BSD auth opens
> wider window against such attack.

I'm not sure what you're trying to show here.  Your second two
(Continue reading)

Permalink | Reply | 8 comments |
headers
SODA Noriyuki | 19 Aug 2008 10:13
Picon

Re: BSD Auth

>>>>> On Tue, 19 Aug 2008 01:33:03 -0400,
      "Greg A. Woods; Planix, Inc." <woods <at> planix.ca> said:

>>> Previous discussions resulted in nothing really and PAM was blasted
>>> into the tree without taking into account any technical
>>> considerations.
>> 
>> Such summary is unfair.

> I think it's pretty fair.  No consensus was reached on the contentious  
> points

Hmm, the discussion was made at a mailing list that only netbsd
developers' can read/write it.  So you couldn't see it.
I agree the discussion should be done at public place, and I'm sorry for
that.  But the consensus was made there.

>> From some points of view, PAM is more secure than BSD Auth, and that
>> was one of reasons why PAM was choosed.

> I've never seen any real technical evaluation showing PAM to be more  
> secure.
> 
> Show me where the evaluation is.

See below.

>> With PAM, password attack can be only done via programs who already
>> own root privilege.  With BSD auth, anyone can do password attack.
>> For practical example, "pkgsrc/security/pam-pwauth_suid" implements
(Continue reading)

Permalink | Reply | 7 comments |
headers
markucz | 19 Aug 2008 10:40
Picon
Gravatar

Re: BSD Auth

> I use the following settings in my mk.conf (plus there should be some  
> changes to some makefiles and to the sets lists, but I haven't got  
> around to them yet):
> 
> 	MKPAM =         no
> 	USE_PAM =       no

Well, blow me down! I'm still using my old mk.conf. I haven't even noticed
there's MKPAM and USE_PAM. Lots of thanks for the tip, Greg!

> > I've lived happily without it so far. I don't mind having it in base, I'm
> > just curious whether it's possible to replace its functionality by BSD
> > Auth. I managed to find some code written in 2003 and now I'm examining
> > it to see what can be done with it and if it can be somehow integrated
> > alongside with PAM.
> 
> I'm not sure it would make sense to have them integrated together into  
> the same system.  In my estimation they can't really both be there in  
> the same build (certainly not for anyone who wants the full and  
> guaranteed privilege separation offered by BSD Auth), and with a  
> compile-time option the non-default one is sure to bitrot.

I think I can give that code a try :) I suppose I'll have to start with an
older release, probably 1.6 or 2.0, and then gradually upgrade to 3.0 or
maybe 4.0 with PAM disabled.

> One can try porting the BSD Auth code from OpenBSD.  I have not yet tried
> that myself.

That occured to me too, only I'm not sure it'll be easier than the solution
(Continue reading)

Permalink | Reply | 0 comments |
headers
Greg A. Woods; Planix, Inc. | 19 Aug 2008 17:27
Picon
Favicon

Re: BSD Auth


On 19-Aug-08, at 4:13 AM, SODA Noriyuki wrote:
>
> Hmm, the discussion was made at a mailing list that only netbsd
> developers' can read/write it.  So you couldn't see it.
> I agree the discussion should be done at public place, and I'm sorry  
> for
> that.  But the consensus was made there.

"Sorry" doesn't cut it here.

This issue is (still) a little too important.

Especially when it seems the decision was clouded with FUD and  
misinformation.  Perhaps it was just a case of ignorance is bliss?

As I said back in 2003:

You have also totally failed to show any _technical_ justification for
the PAM API.  Where is your evaluation?  What qualities did you compare?
What existing real-world applications using each API did you compare and
what metrics did you use to compare them?

> PAM uses traditional UNIX privilege mechanism to access password
> database.  So, programs which already have root privilege can access
> the password database (master.passwd).

Indeed -- that's one of the problems with PAM.  It doesn't offer full  
privilege separation.  Programs which don't need access to the  
password database never the less are given such access unnecessarily.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Greg A. Woods; Planix, Inc. | 19 Aug 2008 17:37
Picon
Favicon

Re: BSD Auth

On 19-Aug-08, at 4:13 AM, SODA Noriyuki wrote:
>
> Think about X11 screen-lock program which tries to access user's
> password.  As you know, X11 programs are big and may have a security
> problem, so let's assume the screen-lock program has a hole.

Also, way back in 1998 David Holland wrote the following about the  
fallacies of poor screen lock program design:

     Why should my login password have anything to do with unlocking my
     screen? This strikes me as a bad idea in general.

     What about passwordless accounts where you get access via .shosts  
or
     ssh keys or weird site-specific systems? Even if you use PAM,  
some of
     these just plain won't work with xlock. Of course, this in itself
     doesn't mean that people who have login passwords and want to use  
them
     shouldn't, necessarily, but I really don't see that typing an 8- 
letter
     word is a big strain.

     Ok, so I don't have a good argument against it, but I don't think
     "xlock should be able to look up my password" is a good argument to
     use when discussing authentication system designs.

(from <URL:http://mail-index.netbsd.org/current-users/1998/11/23/0044.html 
 >)
(Continue reading)

Permalink | Reply | 3 comments |
headers
David Holland | 20 Aug 2008 03:02
Picon

Re: BSD Auth

On Tue, Aug 19, 2008 at 11:37:25AM -0400, Greg A. Woods; Planix, Inc. wrote:
> Also, way back in 1998 David Holland wrote the following about the 
> fallacies of poor screen lock program design:
>
> [...]
>
>     What about passwordless accounts where you get access via .shosts or
>     ssh keys or weird site-specific systems? Even if you use PAM, some of
>     these just plain won't work with xlock. Of course, this in itself
>     doesn't mean that people who have login passwords and want to use them
>     shouldn't, necessarily, but I really don't see that typing an 8-letter
>     word is a big strain.

For the record, the latter means "typing in an unlock password when
locking the screen", the same way lock(1) works.

However, in a broader context, this doesn't matter. There are also
other window-system programs that really do need to be able to check
passwords, such as xdm. Many of them have had security issues over the
years.

PAM has a number of more fundamental problems than the lack of
privilege separation; however, as I recall bsdauth isn't really a
credible alternative, nor for that matter does it really address those
problems properly.

A real solution will, among other things, not require getty and login
to run as root. This solution does not currently exist.

--

--
(Continue reading)

Permalink | Reply | 2 comments |
headers
David Holland | 20 Aug 2008 03:07
Picon

Re: BSD Auth

On Tue, Aug 19, 2008 at 05:13:11PM +0900, SODA Noriyuki wrote:
 > > [kerberos]
 > The authentication module of PAM runs inside of the caller's process,
 > so it's possible to change the state of the process.
 > The authentication module of BSD Auth runs as a differnet process
 > from the caller's process, so it's impossible.

Nonsense. The application process needs to be able to communicate with
the bsdauth process anyway; there's nothing inherent that prevents
such communication from including Kerberos tickets.

Whether bsdauth as it currently exists is actually capable of doing
this properly is another question; but it's also not entirely clear
that PAM as it exists can do this properly either.

--

-- 
David A. Holland
dholland <at> netbsd.org
Permalink | Reply | 1 comment |
headers
Joerg Sonnenberger | 20 Aug 2008 14:30
Picon

Re: BSD Auth

On Wed, Aug 20, 2008 at 01:02:46AM +0000, David Holland wrote:
> A real solution will, among other things, not require getty and login
> to run as root. This solution does not currently exist.

I don't think getty has to run as root, it just needs to be in the right
group to access the terminal device. login needs the privilegese to
change permissions on the tty and to write to /var/run.

Joerg
Permalink | Reply | 0 comments |

Gmane