similar to: interested tru64 unix person - privsep patch against 3.4p1 + howto /regress

What do we loose by not having post-auth privsep? What code is executed between authorization and actual setting of the effective uid? On Tue, 3 Sep 2002, Chris Adams wrote: > Once upon a time, Toni L. Harbaugh-Blackford <harbaugh at nciaxp.ncifcrf.gov> said: > > It appears that the integration of the sia session setup will either > > have to be rethought or abandoned

Hi- Since the tru64 patch was designed for -current, I thought I would try to build it with a recent snapshot before backporting to 3.4p1. So I downloaded openssh-SNAP-20020826.tar.gz frpm the portable snapshots, but it does not contain the 'configure' script. I tried copying the 'configure' from 3.4p1, but that does not create a Makefile from the Makefile.in. Where are the

Hi- Under privsep, I experimented with moving the session_setup_sia() out of do_child() and into do_setusercontext(), which is where the uids/gids are set to the final execution user. The call is made with a NULL tty, and this is functional provided that any later pty allocation uses grantpty() to set the device permissions. Logging in with this method shows that a utmp entry does get made for

Hi- I applied the privsep patch to Tru64 5.1A openssh 3.4p1 and it *almost* works. I get in from the client side and xauth is run, but in the meantime the server side disconnects. Running sshd in debug mode level 3 gives the following output: . . . debug1: session_input_channel_req: session 0 req shell debug1: fd 5 setting TCP_NODELAY debug1: channel 0: rfd 13

Hi- I built openssh-3.0p1 on a Tru64 4.0G without any problem. The system uses enhanced security, so the sia_* routines are used by sshd. Unfortunately, password authentication fails because sia_ses_authent() returns 0 in auth-sia.c. The thing is, the password is CORRECT; I verified this by inserting debugging statements before the call to sia_ses_authent(). The call to sia_ses_init()

Hi Toni, I'm sorry, I haven't had much time to work on this today. When I run sshd (from the patched snapshot) in a debugger, with a breakpoint early in setup_sia(), this is what I find after connecting with a client: (1) There are two sshd processes. One is running as root, and the other as the user I logged with using the client. The root process is the one in the debugger,

OK, I got a chance to try out the Tru64 patch for privsep. I applied the patch to 3.4p1. Partial success, in that it now works for me for logins to "root". Logins to ordinary accounts fail after authentication, when trying to set tty characteristics. See the excerpt from the debug messages below. This is for Tru64 V4.0F (with enhanced_security turned on, obviously.) I guess it's time

A patch for a few more hiccups and trivialities in kinit.c: * The check_path() calls check for "/root" and "/old_root" - I believe that should be "/root" and "/root/old_root". * chdir("/") is recommended after pivot_root() * init_argv[0] isn't set properly to the basename pointed to by char *s - this fix also eliminates six lines of

kinit/nfsmount.c:mount_nfs_root() should use the bootpath specified by bootp/dhcp. If the "nfsroot" option is specified then it overrides the boot server bootpath and a message indicating the override is printed. --- klibc-0.194/kinit/nfsroot.c.orig 2005-01-05 04:13:47.043897880 -0700 +++ klibc-0.194/kinit/nfsroot.c 2005-01-05 04:13:09.316633296 -0700 @@ -66,34 +66,21 @@ const int

Fix an off-by-one in asprintf and vasprintf. The return of vsnprintf is the number of bytes *not* including the terminating '\0'. The size argument to vsnprintf is the number of bytes *including* the terminating '\0'. diff -u klibc-0.188/klibc/asprintf.c udev/klibc-0.188/klibc/asprintf.c --- klibc-0.188/klibc/asprintf.c 2004-10-22 12:07:22.678906352 -0600 +++

I have a hotplug setup in initramfs. Everytime that modprobe is called I get a kernel oops: NULL pointer dereference: Unable to handle kernel NULL pointer dereference<1>Unable to handle kernel NULL pointer dereference at virtual address 00000014 printing eip: c015db49 *pde = 00000000 Oops: 0000 [#1] PREEMPT SMP Modules linked in: CPU: 3 EIP: 0060:[<c015db49>] Not tainted

Patch to guarantee __optptr initialization and to correctly increment optind for missing arguments. --- klibc-0.194/klibc/getopt.c.orig 2005-01-04 23:18:50.229222640 -0700 +++ klibc-0.194/klibc/getopt.c 2005-01-04 23:17:05.236184008 -0700 @@ -11,7 +11,7 @@ char *optarg; int optind = 1; int opterr, optopt; -static const char *__optptr; +static const char *__optptr = NULL; int getopt(int

I'm wondering where things are on the roadmap for klibc and initramfs/early userspace. When will everything be harmonized with the kernel and be the default? What is left to do? I'm in my own little world, but I have a pretty good klibc/hotplug/udev/kinit early userspace that just works (for me). It's taken me a bit to get things to work because I just couldn't find all the

Hi, I just came across this box [0] (McKay Creek). Seems to be exceptional building material for ZFS based NAS/iSCSI unit. I especially liked the two extra system disks hidden inside the box ! Any one have an experience with these ? [0] http://www.intel.com/design/servers/storage/ssr212mc2 -- Regards, Cyril

I''m wondering if the new Dell Precision 490 workstation is/looks to be VT-ready, planning it for SuSE10.1/Xen and unmodifies Windows guest? From the system specs: 1-2 Dual-Core Intel Xeon 5000 series 64-bit processors Intel 5000X chipset Windows XP/Vista or Redhat EWS4 Linux

As I understand it, the idea behind privsep is to prevent malicious data from the client-side of a connection corrupting a server-side process running as root. To achieve that, it is important that post-auth privilege separation happen, ie, that the sshd process change uid to the (authenticated) user. But it is also true that this very same process can perform root-level work without risk of being

Well, after digging around and thinking some more, I'm giving up on the idea of preallocating a TTY to get post-auth privsep working on Tru64. I don't think it will work, because just allocating a TTY doesn't fix the problem - there's no valid way to tie that TTY back to the client process (because it hasn't requested a TTY yet and may not ever do so). The problem is that the

Well, I had just finally gotten around to downloading a snapshot to test the latest on Tru64 a couple of days ago but hadn't had a chance to build it yet, and 3.7p1 has now been released. Sigh. The problem is that Tru64 setreuid() and setregid() are broken, so privsep doesn't work. This could also be a security problem for SIA authentication in general (any version of OpenSSH on Tru64,

Ok.. I need wider testing for this. I'm getting reports back it works mostly. 'ssh site ls' fails, but they can login with Privsep enbled. Can I get those who are using Tru64 or OSF/1 that have SIA enabled to test? This should apple to either -cvs or the current snapshot (I would perfer not to use 3.4p1 due to bugs). I'm going on a trip next week and will be around very spotty

Tru64 patch will not make it into 3.5 (this is final) due to lack of willing people to test. I have given the Tru64/osf1 community almost a month to test it. And *ONE* person came forward to give me verification. And don't give me shit about "I don't have time." The person who tested it was LEAVING his employer with Tru64. He found time. IT IS YOUR GAWD DAMN PLATFORM. IF