[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: root password is not stored in /etc/cipux/



Hi,

On Tuesday 12 December 2006 20:23, Finn-Arne Johansen wrote:
> Christian Kuelker skrev:
> > On Tuesday 12 December 2006 13:10, Finn-Arne Johansen wrote:

> Well, I've read all your mails, and to me it seems like you mean that
> when you do a clean install, of both Skolelinux 1.0 (Venus) and
> Skolelinux 2.0 (and since nothing has until now, also for Skolelinux
> 3.0), you will have the choosen root password stored, not in clear text,
> but scrambled, obfuscated or call it whatever you want, you will get the
> root password you entered while installing the server if you run this
> command:
>  tdbdump /var/lib/samba/secrets.tdb

ok, like I said.

> This is wrong, and has been, since oen of the prereleases for Skolelinux
> 1.0. I Know this for a fact, because I changed this behaviour before we
> relased Skolelinux 1.0, and the script that sets up samba on DebianEdu
> has changed very little since then.

So you mean that the password should be set different while or short after
the installation.  I would never disagree.

> > We have 3 etities:
> >
> > cn=admin
> > cn=smbadmin
> > cn=cipadmin
>
> I know why you need smbadmin, that's because you dont want to store the
> ldap admin password in /var/lib/samba/secrets.tdb.
>
> But why you need to have a cipadmin user, I dont understand.

Well I can take the cn=admin for accessing the LDAP or cn=smbadmin.

I will not explain it twice. So I will ask the question: why does samba need 
cn=smbadmin? Find a solution without.

I know that you know that this is not possible (You said that in your mail)

samba is a kind of layer for users. 

cipux also.

> > All of then could have 3 different password hashes in LDAP.
> > The passord is of smbadmin is stored in clear text on HD.
>
> I dont quite agree that it's in cleartext, but I kind of agree with you.

ok. wee agree that it is readable by root and that it is on the HD.

So in terms of smba skolelinux trusts the filesystem.

> > and we have (posix) user root with an encrypted password stored in shadow
> >
> > which must be identical to the 3 others, but was identical at least till
> > sarge.

I think here is a mistake of me (I wrote to fast). This 3 must NOT be 
identically, But I know a lot of systems where cn=admin and (posix) root and 
cn=smbadmin are (till sarge at least.).

> Please read those 3 (4?) lines again. And do a clean install of either
> one of the releases, and then do tdbdump ...
> I would be very surprised if you do get the same password as the one you
> entered as root password....

??

> >> It could be,  but by default it's not the same.
> >
> > On Every sarge and woody system which was installed and not modified, it
> > was the same.
>
> No, it was not. See my mail earlier.

Well we might not come together in this matter. But for the argumentation it 
is not so important what was the case, it is more important what will be the 
case for 3.0 And if the passwords must not be identical and if they would not 
be identical by a plain installation from a normal user without fixing hat 
after installation, then this is very very good.

So we should be concantrate on the future.

> > Or has this changed in etch?
>
> not that I know of, but I'm not that involved anymore ....

ok

> > (I ask this question now more than once in this tread, and no answer till
> > now.)
> >
> >> Normally, noone knows the password for the smbadmin ldap user, unless
> >> they've done a tdbdump /var/lib/samba/secrets.tdb
> >
> > if its not the same, yes.
>
> By default it's not the same....

An why it is equal on several sarge system I looked today?
(But we can skip that answer, we should made a vote for that)

> >> And with the default settings, it should not be possible to generate a
> >> normal user account, to be used for logging in on the system.
> >
> > good.  (but you are not 100% sure, aren't you?)
>
> I have an idea that some maybe could investigate if it's possible to
> exploit, but I want to discuss that internally in the security-team first.

So I am not part of that  team, please let me know the answers.

But I am quite sure, that the solution (whatever that might be) will
fit also for cipux. 

> >> To get a working samba implementation, it's not possible to _not_ store
> >> this password hashed in /var/lib/samba/secrets.
> >
> > This is exactly what I mean!
>
> But it's possible to get it more secure then today, but that means that
> the machine accounts would have to be created from an ldap-based
> Administration tool before the machines are joined.

yes they could be created that way. And they may be should be created that 
way. I did it since 1999 this way. But it is also possible to let the windows
client trigger samba for doing that. And that is what teachers ask for.

> > And pere should understand that this is also true for every other
> > Samba like framework which have to connect to the LDAP server,
> > like CipUX.
> >
> >> It is however possible
> >> to make it impossible to use that password to create new accounts. to do
> >> this, you have to create the machine accounts before joining the
> >> machines to the domain.
> >
> > well and how dos samba retrieve LDAP information without a password? You
> > know that SAMBA do a lot of LDAP queries in a productive environment.
> > Even after machine accounts have been created.
>
> I know, but it's easy to limit what attributes that the smbadmin account
>  are allowed to update/add.

Ok then this must apply also for cipux. We need ACL rights to limit the 
attributes or the scope.

My suggestion is that cn=admin, cn=... should not be under the same tree
as normal users. 

The ACLs then can then be easier. 

Greetings
Christian





Reply to: