Kernel Traffic
Latest | Archives | People | Topics
Wine
Latest | Archives | People | Topics
GNUe
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic
 

Samba Traffic #13 For 23 Feb 2000

By Peter Samuelson

Table Of Contents

Introduction

Luke Leighton has started releasing alphas of his Samba-TNG code. He has released six so far; they are accessible in ftp://samba.org/pub/samba/alpha/. Perhaps this means he is trying to move this code towards a stable release, or perhaps it means he doesn't think enough people are willing to use CVS to test the code. One data point in support of the first hypothesis is that this week, for a change, Luke did not undertake any major effort to reorganize the entire TNG code base.

No official word on when Samba 2.0.7 (the point release currently being hammered into shape) will come out the door. Likewise, no word on Samba 3.0, the long-long-long-awaited fully-Windows NT-compatible primary domain controller release.

Mailing List Stats For This Week

We looked at 542 posts in 1199K.

There were 199 different contributors. 83 posted more than once. 64 posted last week too.

The top posters of the week were:

1. ACL Implementations Discussed

10 Feb 2000 - 15 Feb 2000 (25 posts) Archive Link: "NT ACL / Security descriptor checking function"

People: Luke LeightonMichael StockmanDave Collier-BrownElrondJohn MalmbergDan KaminskyJean François MicouleauTim Cole

Luke Leighton started thinking about Windows NT ACLs again. (An ACL -- access control list -- is a table, associated with a file or other resource, that grants or denies specific permissions to specific users and groups on the system. They are pervasive in Windows NT, since NT has no other form of file security. Most Unix systems implement some sort of ACL support, but in practice, they are usually used sparingly, since standard Unix file permissions are flexible enough for most needs and are much easier to manipulate and keep track of. Linux, at least in the standard distributions, does not yet support ACLs.) He posted to samba-technical: "well, i mentioned that we needed this function about four, six and twelve months ago. no response. now, i take it, that people are starting to realise why it's needed. so, if someone implements it, i'll use it. deal?" He gave some hints for how to go about implementing this, and concluded: "any volunteers, please sort it out amongst yourselfves on the samba-technical list. no volunteers, i carry on with mapping to unix-files and unix-permission checks until there are."

Michael Stockman noted that Luke had mentioned using RIDs, and asked if he really meant SIDs -- yes, that is what Luke meant. Michael had some other ideas about Luke's proposed implementation. He also took issue with Luke's opening statement about "why it's needed": "You frequently fail to fit your explanations into a proper structure." To which Luke answered: "*sigh*. i know. by the way, i apologise for the original message, i had been going 18 hours straight by that point and consequently feeling ... less inclined to diplomacy. the public mailing list equivalent of a 3am letter :)"

Dave Collier-Brown remembered a "Grey Book" which researched various issues surrounding the mapping of ACLs to the original Unix permission model. "It's wordy and boring, but they did a very thorough job. Aha! found it on-line: http://www.fas.org/irp/nsa/rainbow/tg020-a.htm" He went on explain his interest in ACLs: he was a "former Multician and, later, Professional Paranoid" . Luke thanked Dave for the pointer and dug into the text with no little enthusiasm.

Talk turned to how best to map NT-style ACLs to whatever might be on the target Samba system -- not all ACL implementations are semantically equivalent, and NT uses the VMS model which is one of the more flexible ones. Michael's take on this: "Actually, what I want is a "can do it all" ACL implementation. And that is why we must own the implementation, not be depending on someone not having this requirement. I don't trust that NT ACLs is a superset of all ACL implementations." Luke agreed, somewhat, but was in favor of making a simplifying assumption: "my suggestion would be, simply to avoid duplicating effort to produce an ACL api that is a [potential] superset of VMS-security descriptors, is to use VMS-security descriptors as the baseline, until it can be proven that there exists a real-world ACL impleentation that does more." Dave agreed about the VMS security model and later wrote up a quick reference to the Multics security model for comparison.

Elrond brought up an interesting point: "Many Unix-filesystems have special bits, that are not easily mapped to NT-ACLs. The sticky and setgid/setuid-bits come to mind." Luke thought that at least some of those bits had analogues in NT security descriptors (a security descriptor encapsulates a file's ACL and also specifies ownership).

Tim Cole posted to say that he was working on some code to manipulate ACLs in some fashion. But it was Michael Stockman who took up the original baton. He posted under a new thread to announce that he was working on the ACL/security descriptor functions. He gave a detailed implementation report.

John Malmberg responded with a grab bag of implementation ideas and desired features. "I would recommend representing the HIDDEN, READONLY, and SYSTEM attributes as one of these special meaning values." [...] "The reporting of the ARCHIVE bit should be done by a platform dependent routine so that it accurately represent the backup state of the file. Setting the archive bit would have a similar routine, for those platforms that it makes sense. A smb.conf option that specifies if a non-root user is allowed to change the ARCHIVE bit may also be desired." [...] "A default protection and inheritance type is needed. This is implemented in NT 4.0 SP4. The commands to display and manipulate this are in W2K or a patch kit for NT 4.0."

Luke answered, rather uncharacteristically: "john, i think this acl implementation is being considered as an internal samba implementation and won't ever be dropped to disk. it therefore serves as the interface between NT security descriptors and the underlying filesystem. exactly why this is being considered, i really don't know, particularly as samba will not be expected to support anything other than NT security descriptors." Michael explained, "For the time being, I think of it as a superset. We are in fact not only implementing one security model but must be able to seamlessly interface with N security models. As I have no clue what someone might (have) put in an ACL/SD (on any system) I want to be able to store it in the ACL/SD when I get a clue. Luke has suggested duplicating VMS/NT SD/ACL, which is what I in practice am doing (with some modifications). I do refuse to call them NT SDs/ACLs because thay are not, even if they had exactly the same format they wouldn't have been." In a later post: "I don't get why you want an SD implementation that is exactly equal to the NT implementation. Our needs are different from NT's, and thus our implementation will be." Luke's answer:

so, if i get this straight, you think that by providing a generic, combined, internal ACL API that it will make the job of mapping to different ACL implementations easier??? how so??? let me get this straight. you are proposing this, yes?

  windows->sec_desc->internal_acl->trad_unix
  windows->sec_desc->internal_acl->hpux_acl
  windows->sec_desc->internal_acl->solaris_acl
  windows->sec_desc->internal_acl->posix_acl
  windows->sec_desc->internal_acl->sec_desc (native NTFS support)

is this correct? because if so, what's the point of hte internal_acl bit? if you can answer this question, i will stop asking it. [i can actually think of a reason, i'm curious to see if you think likewise]

Michael responded with a proposed API to help explain things. Dan Kaminsky had his own perspective:

Some central scheme is required. Almost all language translation systems out there use an internal "pseudolanguage"(think esperanto) for translating from one context to another.

Now, if that scheme can be contained within the sec_desc, great. That means you have a way of conveniently representing sec_desc internally in a manner that allows functionality beyond that which is contained within the underlying file system.

I'm no expert when it comes to SMB, but I have the off feeling that NT SD's and English are similarly ornery, and both are more accurately contained within a "boiled down" internal_acl.

Jean François Micouleau asked, "and how do I make a SD for a non persistent object ? Like a print job ?" Luke answered, "first of all, do you need an SD for a print job?" Jean François explained, "ME ? no. I don't need an SD, but I need a coffee. GetPrinter level 4 need an SD, that's the hidden side of the security tab->permission on a printer." He continued, "SD are used everywhere, on disk objects, print objects, process, physical ports, washing machine, you can stick an SD on most object in NT. So I propose to go one step further and implement Access Tokens."

Finally, Tim Cole posted an update of what he was actually up to. "I've got some code written here for just such a generic ACL facility (IMO, it really plays a similar role to the sys_* calls in Samba -- abstracts the "native" interface to something more or less generic, while still close to the native interfaces), but I need to clear it with legal before I can release it." Elsewhere: "from my own experimentation, the possible "native" representations are all enough alike that a pretty simple generic representation will handle them. Once you throw NT ACLs into the mix, though... you basically have to reconcile yourself to using NT ACLs where it's appropriate, and then providing a generic API and ACL representation for native kernel objects."

2. Samba MSRPC Implementation Notes

13 Feb 2000 (3 posts) Archive Link: "DCE/RPC over SMB - nt login, code walk-through."

People: Luke Leighton

Luke Leighton got it into his head to post a series of lengthy notes about Samba-TNG's implementation of NT RPC, particularly some special cases. As he explained, "i particularly wanted to write this so that people can follow what is going on, here. it's not exactly trivial, so if anyone wanted to do a code review, they'd need to know how it fits together."

It was all very heavy stuff, but probably should be required reading for anyone planning on doing any serious hacking on the Samba RPC code.

3. The Return of SYSKEY2

13 Feb 2000 - 18 Feb 2000 (6 posts) Archive Link: "SYSKEY2 code, and new random data source"

People: Pete ChownJeremy AllisonDan Kaminsky

Pete Chown started a thread on samba-technical with an announcement and a request for comments:

At Luke's request, I have developed some code which implements the SYSKEY2 scheme for protecting the SAM database. You can get it from:

ftp://ftp.skygate.co.uk/private/flanfield/

There is also a replacement for Samba's random number generator, which produces a random stream based on the SYSKEY2 value. The reason is that I discovered a security hole in the old one, assuming that I understood the code right.

To begin with, assume that we are running on a Unix with a traditional rand() function (not Linux, for example). On the first call to generate_random_buffer(), md4_buf is all zeroes. The rand() function is then seeded with a value which we will assume for the moment is random.

Subsequently there are some cryptographic operations that do quite a good job of mixing everything up. However, a traditional rand() function only has 32 bits of state, so it would be quite feasible to brute force it. Eventually you find a seed that generates the random number stream that you see on the network.

Based on my quick look at the code, I think it may be secure after that; it will gradually accumulate entropy in md4_buf, meaning that as the server continues to run the random numbers will become less predictable. On the other hand, if you had watched the server since it started up, you would be able to break the random number generator "32 bits at a time".

Jeremy Allison corrected him: "This is incorrect. md4_buf is not zeros - it is filled with data from various sources in the function do_reseed()." Pete responded, "That's the worst of trying to understand code without doing anything to test your understanding! Yes, you are quite right." He tried again: "Suppose we have captured a block of random data. Now consider the loop at the end of genrand.c, at the point where block zero has just been written out. At this point md4_buf is equal to block zero exclusive-ored with something derived from the system random number generator. To calculate block one, we calculate md4(md4_buf) and exclusive-or in more output from the random number generator. Don't we have a problem with lack of entropy in the system random number generator here (rather than in the other place). To go from block zero to block one, we just try all possible seeds for the RNG." Nobody responded.

Dan Kaminsky had a feature request. "As long as you're hacking on RNG stuff, mind tossing in support for EGD, the Entropy Gathering Daemon? For "suitably paranoid" types, it'd be nice :-) EGD just creates a socket file you pop entropy off of..." (Sounds a lot like the Linux kernel random number service, i.e. /dev/random and /dev/urandom.) Shouldn't be hard to support, said Pete.

4. Windows 2000 Still Buggy?

15 Feb 2000 (3 posts) Archive Link: "Win2k and Samba TNG"

People: Jacob JensenLuke Leighton

Jacob Jensen posted two problems to samba-ntdom. First: "I cannot get the domain user to have local administartor rights.. when ever i add DOMAIN\DOMAIN ADMINS to LOCAL\Administrator group.. it changes nothing.. i also cannot add my samba server to the domain cause smbpasswd -j DOMAIN errors twice on connection refused and then it says it cannot change the trust account password." Luke Leighton answered this one: "you'll need to set this up on the unix side, manually. you cannot do this at all with samrd --with-sam-pwdb=passdb or --with-sam-pwdb=nt5ldap, and i stalled on the samrd --with-sam-pwdb=tdb project, i have bugs to hunt."

Just when we all thought Windows 2000 was finally bug-free and ready to deploy on all our important servers, Jacob posted his other question: "Another problem i am having is when i go into win2k and get a listing of users in any way.. or look at a security tab with a sid from the DOMAIN.. mmc.exe or explorer.exe crashes.. i cannot explain this one." Luke also answered this one:

nt5's explorer.exe crashes? damn, they were supposed to have made the nt5 code more robust. well, it's client-side, so that means we got things to fix.

however [and this goes to the bcc recipients], problems client-side aren't critical, except there is the possibility of some third party, not-quite-developed server being added to a network, in some fashion, and nt clients (and maybe servers) fall over because some user-action or just general network browsing.

if that happens in LSASS.EXE because, say, the response back from the LsaLookupSids or LsaLookupNames is badly-formed, then a user viewing security permissions of a file on the not-quite-developed server could cause some damage.

plus. other people are using LsaLookupids and LsaLookupNames to look at accounts on, say, 2.0.2 samba servers, and your code [the bcc recipients are at microsoft] is causing memory exceptions in those third-party programs, causing the program to become unstable (particularly if it's a threaded app) or even take out the box the application is running on!

it's not a high priority, but it does need to be fixed.

5. TNG Bug Hunt

15 Feb 2000 (9 posts) Archive Link: "[Samba-TNG] Diagnosis steps fail (repost)"

People: Jamie FfolliottLuke Leighton

Jamie Ffolliott was testing Samba-TNG and ran into problems: "I ran into some 'connection refused' errors on with smbpasswd -j SAMBA to join the domain (following the TNG faq), so I investigated my setup a bit more. Went through the DIAGNOSIS.txt steps and testparm, and found that steps four to six are broken (all the others, 1-3 and 7 work fine). Nothing seems to be wrong in my smb.conf, and I've checked that all the diagnosis steps work with samba-2.0.6 but not with TNG on this machine (using the same smb.conf without PDC features enabled). Essentially all connections to /tmp/.nmb/agent (nmbd socket?) fail." He posted detailed logs of this failure.

Luke responded, "please try using rpcclient -S . -U root% -l log or samedit -S . -U root% -l log (as root) and let me know if createuser yourownsambaservername$ -j works. remember to add yourownsambaervername$ to /etc/passwd." Jamie didn't have much luck: "On the createuser command, it had a segmentation fault." He posted more logs. Luke read them and said: "see? you're using smb, which means you didn't specify -S like i said you had to. please read messages when i send them, i have rs.i i don't want to have to type any more than i have to." Actually, Jamie answered, "Oh I definitely read your messages Luke." He was indeed using the right command line and it was still failing.

In that case, Luke answered, "it should'n't be doing that. you do have lsarpcd and samrd running, yes?" Jamie did. He posted a backtrace of the crash, but Luke asked for a trace of Samba compiled with debug support. No further traffic.

6. Setting Up Trust Accounts Securely

16 Feb 2000 (1 post) Archive Link: "Using rpcclient or samedit to randomise trust account passwords"

People: Luke Leighton

Another post from the estimable Luke Leighton in the "file for future reference" category. This one is security-related. As he explained in the introduction: "when an nt 4.0 workstation or backup domain controller is joined to a domain, the trust account password is set to a well-known initial value. if you are concerned about internal network security, this is not really an acceptable risk: any captured network traffic can be decoded simply from knowing the name of the workstation, which is contained in the network traffic itself. the initial value is changed to a random value... using the initial value as the key to obfuscate the new value." He added that this has been fixed in Windows 2000, as far as he can tell.

People who deploy NT domains and are concerned about Microsoft's security holes should probably just read the whole post. It describes a procedure to get around at least some aspects of this one.

7. NT Authenticating to a Unix Server?

17 Feb 2000 (15 posts) Archive Link: "NIS and NT PDCs?"

People: Paul LussierJerry CarterIain RaeSeth VidalLuke LeightonSteve Langasek

Paul Lussier posted a questiont to samba-ntdom: "Unfortunately, due to the fact that Samba can't yet handle domain trust relationships with other NT domains, I'm forced to use an NT PDC for now. However, since I've recently moved my entire user base over to Unix accounts for e-mail purposes, I'd really rather not have to deal with creating new accounts for them all. Does anyone know if it is possible to have NT authenticate against an NIS server, and if so, how?"

Jerry Carter answered, "For interactive logons, yes there is a GINA replacement that will authenticate against NIS. However, this is not what you need to get a NT DC to validate against NIS." He posted links to http://www.eng.auburn.edu/users/cartegw/win32/tools.html and ftp://ftp.eng.auburn.edu/pub/cartegw/nisgina/.

Iain Rae described one working implementation:

NIS master is on Solaris x86 {lion}
Samba PDC (HEAD branch cvs from about this time last year) on Solaris x86 {barham}

PC's have Humminbird's NFS Maestro installed and are registered to the samba PDC controller.

lion has a perl script which does the following (for admins only)

get password & verify it will work with passwd and smbpasswd update NIS via passwd fire up ssh session to barham set smbpasswd via smbpasswd (creating account if it doesn't exist)

This is used to set up acounts and to fix "I've forgotten my password " type problems.

NT boxes will update both NT (Samba) and NIS passwords (Maestro) off the Ctrl-Alt-Del box.

There is^h will be a perl script (civpasswd) on the suns which wraps passwd and smbpasswd and a couple of other things in a similar fashion to the one on lion but I really need to get ssh working for everyone on everything, including NT, first of all.

I say will be because the unix folks use unix and most of the students just do the Ctrl-Alt-Del thing.

What you want, to keep the passwords synched is the ypbind part of NISgina and a copy of yppasswd that will work with NT (which ought to be possible) and a program or wrapper script which would allow your users to do

  foopasswd

on unix or NT and change both passwords.

Seth Vidal had a further question: "Can I get pam_ntdom to change pws on a samba domain or do I have to install smbpasswd everywhere and write an expect wrapper to passwd?" Luke Leighton responded: "anyone want to write pam_ntpass from pam_smbpass? it's one function call --- literally." Seth said, "if someone does I'll gladly send you whatever pizza you want. I would but I really wouldn't know where to start." So Luke told him how: download pam_smbpass from Steve Langasek's site and hack in the msrpc_sam_ntchange_pwd() function from Samba.

8. PDC Setup Question

17 Feb 2000 (9 posts) Archive Link: "join a SAMBA domain as a PDC"

People: Matt ChapmanLuke LeightonPieter GrimmerinkMatt Geddes

Pieter Grimmerink was unsuccessfully trying to set up an NT domain with Samba-TNG. He fished samba-ntdom for clues. smbpasswd -j wasn't working so he tried rpcclient and samedit, to no avail.

Matt Geddes had the answer. "use lsaquery first to ascertain the SID. When you first start rpcclient, just type lsaquery. It'll hopefully print 2 lines of crud. Then you can use the createuser ..... bit" Luke Leighton had an update: "i dealt with this recently, when i created samedit, because i didn't want samedit to have lsa commands in it. so i automatically ascertain the SID, now." In other words, Pieter had an old version of the Samba suite. (Note that in the Samba-TNG world, "old" does not always mean whan one might think....)

9. Synchronizing Password Changes with LDAP

17 Feb 2000 - 18 Feb 2000 (8 posts) Archive Link: "NT/UNIX password synchronization, using LDAP for pasword store."

People: Paul KennedyLuke HowardJerry CarterPhil Mayers

Paul Kennedy appealed to the fine folks at samba-ntdom for help with password synchronization. As he put it: " I am trying to implement a single sign-on solution for NT/Solaris/Linux. Linux/Solaris is easy, I use nssswitch and pam_ldap to cause the authentication client tools to compare against the same userPassword attribute value of a single user entry in an LDAP directory. Is there some feature of Samba which will cause it to synchronize lmPassword/ntPassword to the the userPassword attribute when an NT password changes ?"

Luke Howard was not sure Samba had access to the unencrypted password in a password change. But, he said, "If SAMBA (when acting as a PDC) does get the cleartext password, then perhaps all you need is a conversation with the ldappasswd program (included with OpenLDAP)." Jerry Carter confirmed that this was the case. "This is fundamentally the same issue as the unix passwd sync parameter. The new password is receiv4ed in the clear (actually not, but it is decrytable). The old password is not available. You can probably just use a custom "password program" setting and get it to work." Luke added, "That should work with OpenLDAP's ldappasswd, a matter of setting the bind DN correctly. It would be less of a hack to have the ldapdb code in nt5ldap update this itself, though."

At this point, Phil Mayers cautioned: "A caveat - then the passwd program string (including the bind DN command line argument and password) will be in the smb.conf file (which is world readable). It's best to have a simple root-only access shell script which does it..." He posted a Perl program that did the trick for him.

10. Windows Registry Size Limits

17 Feb 2000 (1 post) Archive Link: "Profiles/Policies: Beware the Registry Size"

People: Benjamin Kuit

Benjamin Kuit had a problem with profiles and policies under Windows some time ago; he tracked it down and wanted to share the knowledge. He explained that it wasn't really a Samba issue but might be of interest to Samba users:

The problem was that we had the strange phenomenon whereby a particular profile would inhibit the inforcement of policy settings, eg the 'shut down' menu option would show, control panel was accessable, regedit was able to be run etc, and it was unclear why a profile could disable the effects of the policy.

The problem seems to fall to a registry size limit on the NT workstation, which can be accessed by

Control Panel -> System -> Performance -> (Virt. Mem)Change

This brings up the Virtual Memory properties dialog box, and at the bottom of it shows current and maximum registry sizes.

The problem was the maximum registry size was set to the same value as the current registry size, so once the profile was loaded, there simply wasn't any more room for the policy to be loaded into the registry, so the policies dont take any effect, and because it doesn't give any warning messages for not having enough room, it remains a mystery to most people.

This could be a source of alot of 'my policies dont work' type problems.

The moral of the story is: Check the maximum registry size.

 

 

 

 

 

 

Sharon And Joy
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.