Re: [9fans] a few Q's regarding cpu/auth server
On Wednesday 05 August 2009 19:42:54 Anthony Sorace wrote: /sys/log/cron: rc (cpurc): can't open: 'sys/log/cron' is a directory ... not quite sure what to make of that. that's weird. it shouldn't be a directory, just an append-only file like most of the others in /sys/log. not sure how it got directoried. remove and replace. Easy enough! * Could anyone explain or tell me where I can find more information regarding what all is going on with the following: con -l /srv/fscons snip /srv/fscons is the conventional location for you fossil console; see fossilcons(8) for more information, including what uname, fsys, and create do. Aha - thanks, I was looking at fs(8) -- which wasn't helping me. * At one point I created a new user with 'auth/changeuser' that I didn't need/want. What's the suggested means of removing this user? see keyfs(4). remove the directory. Works like a charm. Knowing the the correct manual page(s) to be looking at certainly helps! grin I can't help though but be curious as to why there's no command, or an additional switch to changeuser, to remove users from the keyfile. I guess due to Plan 9's simplicity motto? * Similarly to the question above, how should I delete a user created with uname via fscons? you may or may not realize this, but it's sometimes non-obvious: users on the auth server are different from users on a file server, and they don't need to be the same (depending on what you want). changeuser and keyfs work on the auth server; anything done on fossil's console (/srv/fscons) is on the file server. again, see fossilcons(8). Thanks, yes I was aware (superficially) that there was a difference between users on the auth server and users on the file server. I read through fossilcons(8) though, and I'm still not sure how to delete a filesystem user. I almost got the impression that it's not possible - due to the mention that Once an id is used in file system structures archived to Venti, it is impossible to change those disk structures, and thus impossible to rename the id; but reading on, I guess to remove a user, I just need to manually edit the user table? Will it hose things if I edit /adm/users directly, from a shell, rather than executing 'users [ -r file ]' on /srv/fscons? Again, it's seems lacking that there isn't simply a 'uname -name' switch. (I'm not complaining, just bewildered.) * I hope I don't get beat up on this one (well, I hope I don't get too beat up on _any_ of these questions...), but it seems strange that something as important as a cpu/auth server would just go and boot up right into the hostowner... apparently this a non issue - so what am I not understanding? philosophy. plan9, like research unix before it, recognizes that if you have physical access to the box, all bets are off anyway. Well, sounds like a flawed philosophy taken too far. Flawed, because all bets are not necessarily off with physical access; and taken too far, because... dang, what harm is there in providing that last means of interference to a hostile? Cpu/Fs/Auth server says: If you can touch me, I'm _all_ yours... What a fascinatingly... loose... form of security, if you catch my drift. security consists of locking your door. ... which means bootes is just a quick hacksaw or boltcutter or crowbar away... so why even bother with a locked door? Security is ultimately about the price/time/effort/skills a potential attacker (or vandal) is willing (and able) to put forth in order to overcome a system's security measures. A password is amazingly effective for a vast number of the most common circumstances encountered in many typical environments. Anyhow... I guess there's no reason to argue/debate! Looks like I have some options: if you really, really need to get around that, you have a few options. the closest to out of the box is to install and run a screen locker; a few people have written those, although i'm not entirely certain any are current. more ambitiously, there was a 3rd edition patch to detach the console devices from the cpu server itself, asking for login and treating it as an attached terminal. those are assuredly out of date, but if you really need the functionality, that's where to start. alternately, just run something on the console that doesn't have a quit function. the console doesn't have interrupt functionality. Thanks for the suggestions! That 3rd ed. detached console devices patch seems to be the best path, but probably the least trivial. Cheers, Corey
Re: [9fans] a few Q's regarding cpu/auth server
On Wed, Aug 5, 2009 at 11:15 PM, Coreyco...@bitworthy.net wrote: On Wednesday 05 August 2009 19:42:54 Anthony Sorace wrote: * I hope I don't get beat up on this one (well, I hope I don't get too beat up on _any_ of these questions...), but it seems strange that something as important as a cpu/auth server would just go and boot up right into the hostowner... apparently this a non issue - so what am I not understanding? philosophy. plan9, like research unix before it, recognizes that if you have physical access to the box, all bets are off anyway. Well, sounds like a flawed philosophy taken too far. Flawed, because all bets are not necessarily off with physical access; and taken too far, because... dang, what harm is there in providing that last means of interference to a hostile? Cpu/Fs/Auth server says: If you can touch me, I'm _all_ yours... What a fascinatingly... loose... form of security, if you catch my drift. security consists of locking your door. ... which means bootes is just a quick hacksaw or boltcutter or crowbar away... so why even bother with a locked door? Security is ultimately about the price/time/effort/skills a potential attacker (or vandal) is willing (and able) to put forth in order to overcome a system's security measures. A password is amazingly effective for a vast number of the most common circumstances encountered in many typical environments. I argued this once too, but eventually came around to the Plan 9 way of thinking. Once you have physical access to the machine, it's yours anyway. Just boot the Plan 9 CD and mount the fossil or any of the other possibilities that arise when you are able to physically insert bootable media into a system and force it to reboot. If your Linux system is sitting out, oh no, there's a big scary login prompt! First thing I try is rebooting and adding single to the end of the kernel options. If that doesn't work, I grab a bootable Linux CD, boot it, and mount your filesystem. Unless you're encrypting the disk (probability: low), it's all mine now. I don't remember the procedure, but I'm pretty sure VMS (reputedly one of the most secure OSes, if not the most secure OS, in use today) has a similar option for bypassing the console password on boot, and of course you can always steal the disk and take it elsewhere, mount a new boot tape, etc. John -- Object-oriented design is the roman numerals of computing -- Rob Pike
Re: [9fans] a few Q's regarding cpu/auth server
I imagine this is probably a subject full of landmines, so I don't want to start a war! I won't press the issue, just want to respond to this, and then I'll just leave the status quo well enough alone. I respect those opinions which differ from my own. On Wednesday 05 August 2009 23:30:38 John Floren wrote: On Wed, Aug 5, 2009 at 11:15 PM, Coreyco...@bitworthy.net wrote: On Wednesday 05 August 2009 19:42:54 Anthony Sorace wrote: philosophy. plan9, like research unix before it, recognizes that if you have physical access to the box, all bets are off anyway. Well, sounds like a flawed philosophy taken too far. Flawed, because all bets are not necessarily off with physical access; and taken too far, because... dang, what harm is there in providing that last means of interference to a hostile? snip security consists of locking your door. ... which means bootes is just a quick hacksaw or boltcutter or crowbar away... so why even bother with a locked door? That wasn't a rhetorical question. Why bother locking your door? Any intruder worth his weight in salt can circumvent such a simple security mechanism with ease. Security is ultimately about the price/time/effort/skills a potential attacker (or vandal) is willing (and able) to put forth in order to overcome a system's security measures. A password is amazingly effective for a vast number of the most common circumstances encountered in many typical environments. I argued this once too, but eventually came around to the Plan 9 way of thinking. ( I'm going to repeat what I've already written to someone else offlist ) The Plan 9 way of thinking (wrt the security of physical terminal access) completely undermines, or somehow fails to recognize, the very real fact that there is always a cost/risk effort/reward equation at play. Out of X number of would-be intruders, only a small fraction of those would, under most circumstances, have the balls and the time to dismantle the server without being noticed; versus all those who would (perhaps even out of sheer curiosity/mischievousness) love to get quick and easy, unauthorized access to an open terminal for a quick opportunistic, low-risk look-see, or to play around, or to simply outright f*ck sh*t up and bail. Fact is... I would _rather_ force that rare motivated and prepared intruder into taking down the box... sheesh, at least I'd be alerted that something went wrong rather quickly. Versus having some ghost in the shell merrily have his way with the system for a period of time. It's weird, it seems so obvious. Passwords help with security. Anyone who relies on them too heavily is being foolish; but regardless - they're most certainly a useful and proven preventative measure to a vast majority of likely potential situations. Once you have physical access to the machine, it's yours anyway. Just boot the Plan 9 CD and mount the fossil or any of the other possibilities that arise when you are able to physically insert bootable media into a system and force it to reboot. This assumes that: 1 - the intruder came prepared with a Plan 9 disk 2 - the machine in question does in fact have a cdrom/floppy attached So I say again: whenever you happen to find yourself with physical access to any given computer, it is _not_necessarily_ yours. There are a large number of circumstantial situations that are most often than not likely to make the dismantling of the machine a much higher risk operation. In all those situations, where a screw driver simply is not an option - boy oh boy what fun can be had with a wide open terminal... it's practically begging you to mess around; even if just for a quick couple of minutes before you bugger off. However, it is _certainly_ yours if it's a total no-brainer to simply start entering commands as a privileged user. If your Linux system is sitting out, oh no, there's a big scary login prompt! First thing I try is rebooting and adding single to the end of the kernel options. If that doesn't work, I grab a bootable Linux CD, boot it, and mount your filesystem. Unless you're encrypting the disk (probability: low), it's all mine now. We're talking Plan 9, not *nix. Anyhow - whatever! I can only imagine this has already been gone through before; and it's not going to make me stop using Plan 9 even though I think it's absurd. (c8= Regards! Corey
[9fans] searchfs
I googled around and haven't found anything, but I notice there is a file /sys/src/cmd/aux/searchfs.c, and a corresponding binary aux/ searchfs. The code doesn't seem to explain what it does very well but it piqued my curiosity. What's this do and how is it intended to be used? I don't know exactly what it wants for a database; I tried using /lib/words and it didn't blow up but I'm not sure that's what it needs. I found the /search file will accept strings like 'search=word' but it doesn't seem to have an effect in the filesystem, nor does reading from it produce anything. Any pointers on how to use this? Or is it defunct or some kind of dead end? Thanks, — Daniel Lyons
Re: [9fans] Intel atom motherboard - success at last
This one still has a fan. Is there anything decent *and* fanless out there? Thanks, Roman. Intel's 'netbook' platform (no amd64) -- fanless, uses a 12V DC brick -- for mini-itx: http://www.intel.com/products/desktop/motherboards/D945GSEJT/D945GSEJT-overview.htm Nick
Re: [9fans] USB HDD connection problem
Forgot to mention, I tried to start /boot/usbd manually, i got error messages, it said that the epX.Y and port numbers are busy or something (i dont have the exact error message here, sorry). 2009/8/5 Francisco J Ballesteros n...@lsub.org: It seems you dont have usbd running. El 05/08/2009, a las 17:51, bval...@gmail.com escribió: Hi, I have a problem with connecting USB HDD. When i plug it in, i get this error message: /boot/usbd: /dev/usb/ep5.0: port 8: opendev: can't open endpoint /dev/usb/ep7.0: '/dev/usb' file does not exist I get this after several other tries too, only the ep-number and the port are varied. - usb/disk gives this: usb/disk: /dev/usb: no devs - usbfat: writes: mount: can't open /srv/usb: '/srv/usb' file does not exist cannot mount /srv/usb The USB mouse works. Greetings: Béla [/mail/box/nemo/msgs/200908/45693]
Re: [9fans] a few Q's regarding cpu/auth server
On Thu, Aug 6, 2009 at 8:52 AM, Corey co...@bitworthy.net wrote: I imagine this is probably a subject full of landmines, so I don't want to start a war! I won't press the issue, just want to respond to this, and then I'll just leave the status quo well enough alone. I respect those opinions which differ from my own. On Wednesday 05 August 2009 23:30:38 John Floren wrote: On Wed, Aug 5, 2009 at 11:15 PM, Coreyco...@bitworthy.net wrote: On Wednesday 05 August 2009 19:42:54 Anthony Sorace wrote: philosophy. plan9, like research unix before it, recognizes that if you have physical access to the box, all bets are off anyway. Well, sounds like a flawed philosophy taken too far. Flawed, because all bets are not necessarily off with physical access; and taken too far, because... dang, what harm is there in providing that last means of interference to a hostile? snip security consists of locking your door. ... which means bootes is just a quick hacksaw or boltcutter or crowbar away... so why even bother with a locked door? That wasn't a rhetorical question. Why bother locking your door? Any intruder worth his weight in salt can circumvent such a simple security mechanism with ease. Why lock your door, when you're living in a gated community? I think the bit you are leaving out is the fact that a proper Plan 9 installation needs terminals. Your cpu/auth/filesystem machines can be somewhere safe, with as much physical safety as you need (physical barriers are much easier to set up and administer that electronic ones). If all is set up properly, you will never have to touch those machines again. Unless the machines break and you need to look at the hardware. Your terminal, on the other hand is ephemeral and you have go through the usual security checks if you want to access your cpu and filesystem servers. Robby
Re: [9fans] a few Q's regarding cpu/auth server
I cannot imageine the senario where random people will have access to the cpu/auth/file server's consoles. It just doesn't happen if you are serious about security. However if you want to protect your console against your friends I wrote a script to do it /n/sources/contrib/steve/rc/conslock you may also want to look at screenlock(1) Incidentially I may use this at home to protect my servers console against my 2 year old who rather likes keyboards, though this is a different type of security. -Steve
Re: [9fans] installation Q
hi, did anyone succeed to install out-of-the-box when target HD is /dev/sdE0, and CD is on /dev/sdE1 ? i did not succeed with install on SATA from IDE CD. i ask before i go to buy a SATA DVD. i promise to update wiki 'installation' page when i succeed ;-) yes. i didn't have any problems with that. at the boot from prompt, i typed sdE1!cdboot!9pcflop.gz - erik
Re: [9fans] a few Q's regarding cpu/auth server
Works like a charm. Knowing the the correct manual page(s) to be looking at certainly helps! grin I can't help though but be curious as to why there's no command, or an additional switch to changeuser, to remove users from the keyfile. I guess due to Plan 9's simplicity motto? [...] I read through fossilcons(8) though, and I'm still not sure how to delete a filesystem user. I almost got the impression that it's not possible - due to the mention that Once an id is used in file system structures archived to Venti, it is impossible to change those disk structures, and thus impossible to rename the id; but reading on, I guess to remove a user, I just need to manually edit the user table? Will it hose things if I edit /adm/users directly, from a shell, rather than executing 'users [ -r file ]' on /srv/fscons? the reason there are few provisions for deleting a user, is because that doesn't make much sense if you have a worm filesystem. at best you can remove the user from the active filesystem, but not the dump. this is the same reason that renaming users is difficult. (ken's fs doesn't have this problem since there's a level of indirection between the name and strictly-internal user id.) i just disable the user's authentication and make the user's mailbox unwritable; i've never had a reason to rename a user. - erik
Re: [9fans] a few Q's regarding cpu/auth server
That wasn't a rhetorical question. Why bother locking your door? Any intruder worth his weight in salt can circumvent such a simple security mechanism with ease. [...] Out of X number of would-be intruders, only a small fraction of those would, under most circumstances, have the balls and the time to dismantle the server without being noticed; versus all those who would (perhaps even out of sheer [...] Fact is... I would _rather_ force that rare motivated and prepared intruder into taking down the box... sheesh, at least I'd be alerted that something went wrong rather quickly. Versus having some ghost in the shell merrily have his way with the system for a period of time. It's weird, it seems so obvious. Passwords help with security. Anyone who relies on them too heavily is being foolish; but regardless - they're most certainly a useful and proven preventative measure to a vast majority of likely potential situations. Once you have physical access to the machine, it's yours anyway. Just boot the Plan 9 CD and mount the fossil or any of the other possibilities that arise when you are able to physically insert bootable media into a system and force it to reboot. This assumes that: 1 - the intruder came prepared with a Plan 9 disk 2 - the machine in question does in fact have a cdrom/floppy attached i think you're arguing three ends against the middle. if the intruder is willing to break down doors, the intruder can just take the machines, too. on the other hand, you argue that you'd need to be prepared to use a live cd or whatnot. but that's just not the case. you can smash and grab. or bring a bootable usb stick and either erase or copy files. first step in understanding security is understanding what the real threats are. or that failing, what threats one would like to protect against. for example, in the office there's a lock and alarm on the front door, a lock into the suite but there's no lock on the machine room door, nor the physical consoles. this has increased system availablity. since i've been able to talk people through problems when i wasn't on site. sure anyone in the company could go mess with the fileserver or auth server. but, that wouldn't be too smart. and the sr with the fileserver's storage has hot swap drives. it would be easier to hose the fs by pulling drives than anything else. great plausable deniablity. the disk drives could have gone nuts. in fact the only physical security problem we've had was an accident. somebody pushed the big red button during a machine move. demonstrating that it's hard to get to step one of security: understanding what the real threats are. by the way, if you want to lock the console, it's not hard to write such a program. just do it. - erik
[9fans] nupas update
i just pushed an update of nupas to sources. it fixes a few bugs, including - a recursive sync loop has been eliminated.. (this has been the source of some mystery crashes) - dualing upas/fs operating on the same mbox no longer miss deletions. the fix is less than elegant. also on 27 jul, a crash with truncated mime sections was fixed. it might be that there is still a bug in imap that caused the original problem. but it could also be due to the recursive sync loop. thanks for the bug reports! - erik
[9fans] contrib dir
Hello Geoff, I wanted to ask you for a directory in sources/contrib. I sent an email to cont...@plan9.bell-labs.com some time ago, but it looks like it got lost and some people on #9fans told me to contact with you. I just want to store there some rio and acme patches I have. Thanks in advance (and thank you too for keeping sources up!). Regards, -- - yiyus || JGL . 4l77.com
Re: [9fans] linux reinvents factotum, secstore ...
On Aug 6, 2009, at 12:13 PM, erik quanstrom wrote: poorly. massive, overengineered, and yet lacking: http://lwn.net/Articles/344117 Ugh. A brief apology on their behalf, though. I have been trying to understand the workings of factotum, secstore, auth/keyfs and whatnot for a while and I'm just now starting to get the feeling that I might have a grasp on how all these things work together in concert to do their jobs. There is a propensity to develop software starting from the interface working backwards to the functionality. When enough people reduplicate a functionality, they decide to move the functionality out. This is what you're going to get when you evolve software rather than architect it. One of the things I have been impressed with in Plan 9 is that generally each layer of abstraction is comprehensive. On Linux there is a tendency to have to keep adding more layers upon the layers. This security framework, for example, relies on D-Bus for communication. The appearance of hal, the hardware abstraction layer a few years ago struck me too. Isn't that what the OS is supposed to provide? Maybe it would have been feasible to add whatever it adds if more of the drivers were in user space rather than kernel space. It's easy for me to object to what they're coming up with but it would be hard for me to describe in detail how exactly factotum + all the other stuff encompass it, and I don't think that the paper we have on factotum or the section in nemo's book are sufficient either. As a devil's advocate, in my Mac keychain I have 13 keys related to file shares and 22 WEP keys. I have my SSH key on 24 machines. Then I have 270 web form passwords or internet passwords in my keychain. Does factotum handle web passwords? I'm presuming not but I don't really know because I generally surf with Safari or Firefox outside Plan 9. I'm not complaining about the browser situation, I'm just saying, it seems to me that the average user probably has more website usernames and passwords than everything else combined. That's certainly the case with me. Could factotum be adapt to integrate with a browser and store web form secrets? If so that would be a compelling objection, since it looks like Firefox isn't going to start using their security framework anytime soon. And who can blame them? It already has a ton of dependencies and porting issues and this can only exacerbate it. It might raise our profile a bit if someone who has a comprehensive understanding of the security framework in Plan 9 would write a rebuttal to this announcement, something along the lines of Plan 9: An Integrated Approach to Grid Computing by Andrey Mirtchovski, Rob Simmonds and Ron Minnich. That paper works largely as a refutation of the complexity of the Globus Toolkit. It would also be helpful to people like myself who are recent adopters of Plan 9 and don't have a comprehensive understanding of the security architecture—perhaps because we've been poisoned by systems like Mac OS X Keychain and SSH. — Daniel Lyons
Re: [9fans] linux reinvents factotum, secstore ...
270 web form passwords or internet passwords in my keychain. Does factotum handle web passwords? yes, it does. abaco and hget already use factotum for http passwords. with me. Could factotum be adapt to integrate with a browser and store web form secrets? If so that would be a compelling objection, since it looks like Firefox isn't going to start using their security framework anytime soon. And who can blame them? It already has a ton of dependencies and porting issues and this can only exacerbate it. sure. you could integrate factotum and firefox. - erik
Re: [9fans] contrib dir
Hi Geoff, I would also like to request a directory in sources/contrib, to store a stream wrapper around sam (ssam), a script which uses mk to parallelize a command over a set of arguments (apply), a script to port ksh/bash scripts to rc (torc), et cetera. Many thanks. Jason Catena (jdc)
[9fans] 9base-3
Hi there, I revived the 9base project which was asleep for nearly 3 years som days ago and created a new version based on Russ' plan9port from 20090731. You can download it from: http://code.suckless.org/dl/tools/9base-3.tar.gz its project page can be found at: http://tools.suckless.org/9base and you can also clone it using mercurial as follow: hg clone http://hg.suckless.org/9base Kind regards, Anselm
Re: [9fans] Intel atom motherboard - success at last
On Wed, Aug 5, 2009 at 2:43 AM, Steve Simonst...@quintile.net wrote: I have had loads of problems trying to build a new machine, Erik has helpd way beyond the call of duty, and finally I have a working machine. The problems where: realteck rtl8169 GigE - erik's driver works a treat An intermitant PSU - RMA'ed to supplier SATA - Eriks new sd driver works nicely A PATA DVDRW which devata ignores. So, all sorted but now I need an IDE (parallel) DVDRW drive which does work. I was going to just buy a Plexstor drive as being the reliable name but they seem to be silly money. anyone any suggestions? Hi Steve Its almost the weekend here and I finally had time to try Eriks iso on my atom motherboard. What configuration did you use? I currently have the follwing memory 2Gig sata harddisk 320Gig ide dvdrw liteon I went through all the default during the install and during fmtfossil I got a few matherror something and it crashed. I t wen too fast for me to take notes. I tried again and check the defaults that the installer was setting and decided to diable DMA. It didn't crash after that, however after letting it sit for 11 Hours it is still in fmtfossil stage. I can still the disk activity light so I guess it's still doing fmtfossil. During the install it gave me the follwing disk prep. 30Gig fossil 24Gig isect 240Gig arenas I will try send out some more details later. thanks. fernan -- http://www.fernski.com
Re: [9fans] a few Q's regarding cpu/auth server
On Thursday 06 August 2009 01:19:35 Robert Raschke wrote: On Thu, Aug 6, 2009 at 8:52 AM, Corey co...@bitworthy.net wrote: snip That wasn't a rhetorical question. Why bother locking your door? Any intruder worth his weight in salt can circumvent such a simple security mechanism with ease. Why lock your door, when you're living in a gated community? A few possible answers: Because I'm convinced that multiple redundant layers of security is most effective. Because I _don't_ live in a gated community. Because anyone can hop a fence, the silly pathetic lock (password) on my front door (auth server) is my last line of defense; and it will be immediately and clearly obvious that someone broke in because... well.. they _broke_ in (turned off and dismantled the server)... they didn't just walk in without further ado (began issuing commands as hostowner on the open terminal) and leave without immediate and clear evidence (no broken/missing case, no powered off server and missing drives, etc) Your cpu/auth/filesystem machines can be somewhere safe, with as much physical safety as you need (physical barriers are much easier to set up and administer that electronic ones). If all is set up properly, you will never have to touch those machines again. Unless the machines break and you need to look at the hardware. Meanwhile, here on terra firma, I would like to be able to have my Plan 9 servers sitting on a rack in a common affordable co-lo somewhere. I think the actual root of the situation, is simply that Plan 9 currently tends to reside within domains with much more strict and secure or trustworthy environments vs. being prevalent within the sphere of the great unwashed masses of the industry where strong physical security is either unobtainable, unaffordable, and/or unreliable at best. _Within_such_environments_, simple passwords remain an effective and proven means of _deterrent_ from the most common, random, unforeseen encounters that may occur on a near every day situation. The phone guys have to enter the server room - you trust them with bootes? Various contractors have to enter the server room - you trust them with bootes? The sysadmin forgets to lock the door to the server room before heading out for lunch - you trust all your visitors, customers, affiliates and employees with a terminal sitting at a bootes prompt? The hosting provider has all number of people walking in and out of the server room constantly, every day - you trust each and every one of these random unknown people with a bootes prompt to your co-lo'd cpu server? Now here's the important part -- in each of these cases (those are just a few, it doesn't take much of an imagination - or much actual experience - to come up with countless more), the _real_ concern is _not_ over that rare motivated, focused, risk-taking bad guy with a plan who's come prepared with a screwdriver and usb rootkit and assorted bootdisks... the concern is all the ad-hoc opportunistic, curious and/or malicious passer-by's, armed with nothing more than their fingers, who just might take up the chance to goof around with that open terminal connected to the server. I have a much higher level of trust that X person won't walk off with or dismantle a server vs. the level of trust I have that X person won't execute commands on an open terminal. It's really quite simple. If your servers aren't under you direct control, and they're not guaranteed continually locked behind a bio-metrically secured room under constant video surveillance - then you don't have physical security. If you don't operate within a contained, peer-based trusted environment (lab, research center, spec. dept., etc), then you don't have physical security. Most of the industry at large... does _not_ have trusted physical security. And if you don't have trusted physical security, then an open terminal is beyond the pale of recklessness. Passwords make an excellent form of _additional_deterrent_ under the sort of lowest common denominator environment that tends to comprise the industry at large. (from AnyTec, to Bob's coffee house, to Standford Son's automotive repair, to The Law Offices Of Larry H. Parker, to Data Entry Inc.) I honestly can't believe that this is even up for debate! grin It's just bizarre. I think the bit you are leaving out is the fact that a proper Plan 9 installation needs terminals. Your terminal, on the other hand is ephemeral and you have go through the usual security checks if you want to access your cpu and filesystem servers. That's understood; and I'm well impressed by the way that particular portion of the model works. Ok, well I think I've said all I can possible say -- so unless I get any direct questions I won't follow up on this; I don't want to annoy the list - 9fans is my only means of assistance for this interesting os - plus, I've already been provided with solutions from which I can roll my own. Cheers, Corey
Re: [9fans] Intel atom motherboard - success at last
I went through all the default during the install and during fmtfossil I got a few matherror something and it crashed. I t wen too fast for me to take notes. this is due to the awk problem reported this week. i'll roll up another cd this evening. with ide turned off, you probablly just haven't gotten to the part where awk dies. - erik
[9fans] binary sprint format
Hi, all I'm trying to convert integers in text binary format by sprint(..., %b, i), but 8c issue a format mismatch b INT warning message. Can anyone kindly explain to me my mistake ? Doesn't %b behave like the other integer format specifications ? Thanks in advance adriano
Re: [9fans] a few Q's regarding cpu/auth server
On Thu, Aug 6, 2009 at 4:28 PM, Coreyco...@bitworthy.net wrote: On Thursday 06 August 2009 01:19:35 Robert Raschke wrote: On Thu, Aug 6, 2009 at 8:52 AM, Corey co...@bitworthy.net wrote: snip That wasn't a rhetorical question. Why bother locking your door? Any intruder worth his weight in salt can circumvent such a simple security mechanism with ease. Why lock your door, when you're living in a gated community? A few possible answers: Because I'm convinced that multiple redundant layers of security is most effective. Because I _don't_ live in a gated community. Because anyone can hop a fence, the silly pathetic lock (password) on my front door (auth server) is my last line of defense; and it will be immediately and clearly obvious that someone broke in because... well.. they _broke_ in (turned off and dismantled the server)... they didn't just walk in without further ado (began issuing commands as hostowner on the open terminal) and leave without immediate and clear evidence (no broken/missing case, no powered off server and missing drives, etc) Your cpu/auth/filesystem machines can be somewhere safe, with as much physical safety as you need (physical barriers are much easier to set up and administer that electronic ones). If all is set up properly, you will never have to touch those machines again. Unless the machines break and you need to look at the hardware. Meanwhile, here on terra firma, I would like to be able to have my Plan 9 servers sitting on a rack in a common affordable co-lo somewhere. I think the actual root of the situation, is simply that Plan 9 currently tends to reside within domains with much more strict and secure or trustworthy environments vs. being prevalent within the sphere of the great unwashed masses of the industry where strong physical security is either unobtainable, unaffordable, and/or unreliable at best. _Within_such_environments_, simple passwords remain an effective and proven means of _deterrent_ from the most common, random, unforeseen encounters that may occur on a near every day situation. The phone guys have to enter the server room - you trust them with bootes? Various contractors have to enter the server room - you trust them with bootes? The sysadmin forgets to lock the door to the server room before heading out for lunch - you trust all your visitors, customers, affiliates and employees with a terminal sitting at a bootes prompt? The hosting provider has all number of people walking in and out of the server room constantly, every day - you trust each and every one of these random unknown people with a bootes prompt to your co-lo'd cpu server? Now here's the important part -- in each of these cases (those are just a few, it doesn't take much of an imagination - or much actual experience - to come up with countless more), the _real_ concern is _not_ over that rare motivated, focused, risk-taking bad guy with a plan who's come prepared with a screwdriver and usb rootkit and assorted bootdisks... the concern is all the ad-hoc opportunistic, curious and/or malicious passer-by's, armed with nothing more than their fingers, who just might take up the chance to goof around with that open terminal connected to the server. I have a much higher level of trust that X person won't walk off with or dismantle a server vs. the level of trust I have that X person won't execute commands on an open terminal. It's really quite simple. If your servers aren't under you direct control, and they're not guaranteed continually locked behind a bio-metrically secured room under constant video surveillance - then you don't have physical security. If you don't operate within a contained, peer-based trusted environment (lab, research center, spec. dept., etc), then you don't have physical security. Most of the industry at large... does _not_ have trusted physical security. And if you don't have trusted physical security, then an open terminal is beyond the pale of recklessness. Passwords make an excellent form of _additional_deterrent_ under the sort of lowest common denominator environment that tends to comprise the industry at large. (from AnyTec, to Bob's coffee house, to Standford Son's automotive repair, to The Law Offices Of Larry H. Parker, to Data Entry Inc.) I honestly can't believe that this is even up for debate! grin It's just bizarre. Oh, if we're just protecting against people wandering by who are obviously there by mistake--since we're discounting anyone coming prepared for serious maliciousness--how about just not having a terminal connected to your file server? My cpu/auth/file servers don't have anything connected except an ethernet cable and a remote serial console. Oh, sure, there's a crash cart over in the corner that you could drag over and plug in, but you've decided that we're only talking about opportunists who see a prompt and decide to type some stuff, so it's
Re: [9fans] binary sprint format
On Thu Aug 6 20:03:20 EDT 2009, a.vera...@tecmav.com wrote: Hi, all I'm trying to convert integers in text binary format by sprint(..., %b, i), but 8c issue a format mismatch b INT warning message. Can anyone kindly explain to me my mistake ? Doesn't %b behave like the other integer format specifications ? Thanks in advance i believe you need to update your libc.h. you need pragmas for the b format, which were added 2007/0108. - erik
Re: [9fans] a few Q's regarding cpu/auth server
Short form: on today's machines, if someone gets physical access, you're owned. Not much more to say except that with the kind of features vendors insist on embedding in the systems, you can easily be owned without physical access -- see the recent Black Hat articles, and I'm not naming names so I don't get fired. If the colo is doing their job, and they'd better be!, then physical access is not an issue because it won't happen, or, when it does happen, the people are trusted and won't mess with your box. 9grid.net has been at, first, UNM computing center for 2 years and, second, at LBL for 2 years. In all the time, there have been no issues. The people at those places are trusted. If colo staff can't own it by physical access then you've solved a hard problem and might want to start selling it. In that case, you need hardly worry about trusting your colo, so put it there anyway. Screensaver + password seems rather quaint in light of these realities. ron
Re: [9fans] a few Q's regarding cpu/auth server
On Aug 6, 2009, at 4:47 AM, erik quanstrom wrote: Works like a charm. Knowing the the correct manual page(s) to be looking at certainly helps! grin I can't help though but be curious as to why there's no command, or an additional switch to changeuser, to remove users from the keyfile. I guess due to Plan 9's simplicity motto? [...] I read through fossilcons(8) though, and I'm still not sure how to delete a filesystem user. I almost got the impression that it's not possible - due to the mention that Once an id is used in file system structures archived to Venti, it is impossible to change those disk structures, and thus impossible to rename the id; but reading on, I guess to remove a user, I just need to manually edit the user table? Will it hose things if I edit /adm/users directly, from a shell, rather than executing 'users [ -r file ]' on /srv/fscons? the reason there are few provisions for deleting a user, is because that doesn't make much sense if you have a worm filesystem. at best you can remove the user from the active filesystem, but not the dump. this is the same reason that renaming users is difficult. (ken's fs doesn't have this problem since there's a level of indirection between the name and strictly-internal user id.) i just disable the user's authentication and make the user's mailbox unwritable; i've never had a reason to rename a user. It also seems that most of organizations I know have that same kind of permanency in place even at HR level. If you leave the company and then get rehired you feel like you've never left -- you badge id and sorts of HR assigned credentials are simply enabled, not created anew. Don't know whether this is a function of IT influencing HR decisions or whether there's an HR reason for doing it that way. Thanks, Roman.
Re: [9fans] 9base-3
On Aug 6, 2009, at 1:08 PM, Anselm R Garbe wrote: Hi there, I revived the 9base project which was asleep for nearly 3 years som days ago and created a new version based on Russ' plan9port from 20090731. You can download it from: http://code.suckless.org/dl/tools/9base-3.tar.gz its project page can be found at: http://tools.suckless.org/9base and you can also clone it using mercurial as follow: hg clone http://hg.suckless.org/9base So, is this just a slimmer version of plan9port? Thanks, Roman.
Re: [9fans] binary sprint format
i believe you need to update your libc.h. you need pragmas for
the b format, which were added 2007/0108.
- erik
I'm using a distribution downloaded about 2 months ago. The machine has
been installed from scratch.
perhaps you have not included everything necessary?
; cat fmtb.c
#include u.h
#include libc.h
void
main(void)
{
print(%b\n, 16);
exits();
}
; 8c -FVTw fmtb.c 8l fmtb.8 8.out
1
- erik
Re: [9fans] a few Q's regarding cpu/auth server
On Thursday 06 August 2009 17:01:30 John Floren wrote: On Thu, Aug 6, 2009 at 4:28 PM, Coreyco...@bitworthy.net wrote: snip I honestly can't believe that this is even up for debate! grin It's just bizarre. Oh, if we're just protecting against people wandering by who are obviously there by mistake--since we're discounting anyone coming prepared for serious maliciousness--how about just not having a terminal connected to your file server? Ok, that's reasonable. Especially when considering the idea that, apparently, once a Plan 9 cpu/auth/fs server has been set up, there's no reason to require further periodic access to its terminal. Removing the Plan 9 server's terminal peripherals is equivalent to - and follows the same exact line of reasoning for - implementing a password for said server's terminal. i.e. - both techniques increase the level of difficulty and effort and inconvenience one must suffer through before gaining unauthorized access to a hostowner prompt. In light of this, I'm still unconvinced that a terminal password is totally without merit. At least with a password, I don't force trusted admins to lug out the peripherals. My cpu/auth/file servers don't have anything connected except an ethernet cable and a remote serial console. Oh, sure, there's a crash cart over in the corner that you could drag over and plug in, but you've decided that we're only talking about opportunists who see a prompt and decide to type some stuff, so it's not a problem. True. The whole friggin' point of a colo is that you trust the people running it-- I have direct experience as a contractor where I have entered many a co-lo; and was unimpressed with their security to say the least. I had constant and easy access to a large number of nameless servers, it's a nobrainer to access keyboard/monitor pairs in many of these places. Interestingly enough - that simple, worthless password prompt is what made it effectively impossible to do anything with said servers. It was easy for me to reach keyboards; but would have been risky and difficult - and would have had _zero_ plausible deniability - to pop a chassis and snag hard drives. I have not found a single sign that anyone has so much as touched the keyboard, much less done rm -r / or whatever it is you're afraid of. I'm afraid of all the same things you're afraid of - all the same reasons why authentication is necessary when accessing the server remotely. As far as I'm concerned, physical access to the terminal is no different than remote access. I differentiate between the server's terminal and the server's chassis, though they are often within reaching distance of each other. To conflate the terminal with the server, as Plan 9 servers apparently do, is a lazy and unnecessary abstraction in my mind. I'm afraid you'll have to forgive me if I find the probability of someone improperly accessing your headless colo'd box rather low. I invite you, though, to create some form of logging protection system for the box. Put the box in a colo, and then in 3 years send us your logs. I guess we'll see how many people tried to get into your cpu server. The co-lo situation was just one example. I agree the risk is sleight - after all, there are _lots_ of servers in a co-lo. So what's the chances of _mine_ getting abused? On Thursday 06 August 2009 17:17:19 John Floren wrote: A note, please don't take this as a flame. Not at all! It's good to hear others experiences and conclusions. Cheers, Corey
Re: [9fans] binary sprint format
erik quanstrom wrote: On Thu Aug 6 20:03:20 EDT 2009, a.vera...@tecmav.com wrote: Hi, all I'm trying to convert integers in text binary format by sprint(..., %b, i), but 8c issue a format mismatch b INT warning message. Can anyone kindly explain to me my mistake ? Doesn't %b behave like the other integer format specifications ? Thanks in advance i believe you need to update your libc.h. you need pragmas for the b format, which were added 2007/0108. - erik I'm using a distribution downloaded about 2 months ago. The machine has been installed from scratch. adriano
Re: [9fans] a few Q's regarding cpu/auth server
don't forget to take away the connectors from the power and reset buttons, otherwise good security concepts;)
Re: [9fans] binary sprint format
erik quanstrom wrote:
i believe you need to update your libc.h. you need pragmas for
the b format, which were added 2007/0108.
- erik
I'm using a distribution downloaded about 2 months ago. The machine has
been installed from scratch.
perhaps you have not included everything necessary?
; cat fmtb.c
#include u.h
#include libc.h
void
main(void)
{
print(%b\n, 16);
exits();
}
; 8c -FVTw fmtb.c 8l fmtb.8 8.out
1
- erik
Your example works on my machine too.
What could be the reason why 8c complains about sprint(buf, %b, 16) in
a driver whose includes are:
#include u.h
#include ../port/lib.h
#include mem.h
#include dat.h
#include fns.h
Am I using them in a wrong way ?
adriano
Re: [9fans] a few Q's regarding cpu/auth server
It also seems that most of organizations I know have that same kind of permanency in place even at HR level. If you leave the company and then get rehired you feel like you've never left -- you badge id and sorts of HR assigned credentials are simply enabled, not created anew. Don't know whether this is a function of IT influencing HR decisions or whether there's an HR reason for doing it that way. That's for sure. I just started to work for a company that I did some consulting for about 15 years ago. It was easier paperwork to put me in the system as a part-time employee back then. So when I started again a few weeks ago, my employee ID number was still in the system to the surprise of the HR girl who handled the initial paperwork. BLS
Re: [9fans] linux reinvents factotum, secstore ...
On Aug 6, 2009, at 11:13 AM, erik quanstrom wrote: poorly. massive, overengineered, and yet lacking: http://lwn.net/Articles/344117 This looks like a case in desperate need of Peter Gutmann's Wave Therapy: http://diswww.mit.edu/bloom-picayune/crypto/14238 Whenever someone thinks that they can replace SSL/SSH with something much better that they designed this morning over coffee, their computer speakers should generate some sort of penis-shaped sound wave and plunge it repeatedly into their skulls until they achieve enlightenment. Thanks, Roman.
Re: [9fans] a few Q's regarding cpu/auth server
Incidentially I may use this at home to protect my servers console against my 2 year old who rather likes keyboards, though this is a different type of security. In that situation, the most important security measure it to place the power switch at an altitude beyond the little one's reach. I speak from experience. It was just like a movie; I was moving in slow motion saying noo as I reached to block the power switch from my daughter's finger. I was too late. Fortunately, I hadn't done too much since I last saved... BLS
Re: [9fans] linux reinvents factotum, secstore ...
On Aug 6, 2009, at 12:33 PM, Daniel Lyons wrote: It's easy for me to object to what they're coming up with but it would be hard for me to describe in detail how exactly factotum + all the other stuff encompass it, and I don't think that the paper we have on factotum or the section in nemo's book are sufficient either. As a devil's advocate, in my Mac keychain I have 13 keys related to file shares and 22 WEP keys. I have my SSH key on 24 machines. Then I have 270 web form passwords or internet passwords in my keychain. Does factotum handle web passwords? I'm presuming not but I don't really know because I generally surf with Safari or Firefox outside Plan 9. I'm not complaining about the browser situation, I'm just saying, it seems to me that the average user probably has more website usernames and passwords than everything else combined. That's certainly the case with me. Could factotum be adapt to integrate with a browser and store web form secrets? If so that would be a compelling objection, since it looks like Firefox isn't going to start using their security framework anytime soon. And who can blame them? It already has a ton of dependencies and porting issues and this can only exacerbate it. These are reasonable questions (and many of them have yes as the answer ;-)) but I have a more fundamental objection here: the desktop is just NOT the place for such a functionality to originate from. The very concept of a fixed desktop that resides on a physical piece of hardware that you own feels so 20th century to me. One way or the other the online identity issue is going to be settled. For contenders, though, I'd rather look at: factotum or things like OAuth. I don't think there's a reasonable conversation to be had with folks struggling to provide solutions for taking the pain out of managing plain text passwords. The pain is there for a reason. Thanks, Roman.
Re: [9fans] Intel atom motherboard - success at last
On Aug 6, 2009, at 1:45 AM, Nick LaForge wrote: This one still has a fan. Is there anything decent *and* fanless out there? Thanks, Roman. Intel's 'netbook' platform (no amd64) -- fanless, uses a 12V DC brick -- for mini-itx: http://www.intel.com/products/desktop/motherboards/D945GSEJT/D945GSEJT-overview.htm All good stuff, but is it available for less than $1K though? Thanks, Roman.
Re: [9fans] binary sprint format
#include u.h #include ../port/lib.h #include mem.h #include dat.h #include fns.h Perhaps libc.h? ak
Re: [9fans] Intel atom motherboard - success at last
Hi Roman, The price seems to be $118: http://www.mini-box.com/Intel-D945GSEJT-Mini-ITX-Motherboard Thanks dharani On Thu, Aug 6, 2009 at 7:09 PM, Roman Shaposhnik r...@sun.com wrote: On Aug 6, 2009, at 1:45 AM, Nick LaForge wrote: This one still has a fan. Is there anything decent *and* fanless out there? Thanks, Roman. Intel's 'netbook' platform (no amd64) -- fanless, uses a 12V DC brick -- for mini-itx: http://www.intel.com/products/desktop/motherboards/D945GSEJT/D945GSEJT-overview.htm All good stuff, but is it available for less than $1K though? Thanks, Roman.
Re: [9fans] linux reinvents factotum, secstore ...
On Aug 6, 2009, at 7:39 PM, Roman Shaposhnik wrote: On Aug 6, 2009, at 12:33 PM, Daniel Lyons wrote: It's easy for me to object to what they're coming up with but it would be hard for me to describe in detail how exactly factotum + all the other stuff encompass it, and I don't think that the paper we have on factotum or the section in nemo's book are sufficient either. As a devil's advocate, in my Mac keychain I have 13 keys related to file shares and 22 WEP keys. I have my SSH key on 24 machines. Then I have 270 web form passwords or internet passwords in my keychain. Does factotum handle web passwords? I'm presuming not but I don't really know because I generally surf with Safari or Firefox outside Plan 9. I'm not complaining about the browser situation, I'm just saying, it seems to me that the average user probably has more website usernames and passwords than everything else combined. That's certainly the case with me. Could factotum be adapt to integrate with a browser and store web form secrets? If so that would be a compelling objection, since it looks like Firefox isn't going to start using their security framework anytime soon. And who can blame them? It already has a ton of dependencies and porting issues and this can only exacerbate it. These are reasonable questions (and many of them have yes as the answer ;-)) but I have a more fundamental objection here: the desktop is just NOT the place for such a functionality to originate from. The very concept of a fixed desktop that resides on a physical piece of hardware that you own feels so 20th century to me. One way or the other the online identity issue is going to be settled. For contenders, though, I'd rather look at: factotum or things like OAuth. I agree, and I think this is one of the most attractive things to me about Plan 9. I don't think there's a reasonable conversation to be had with folks struggling to provide solutions for taking the pain out of managing plain text passwords. The pain is there for a reason. I couldn't agree more. One of the first things that piqued my interest in Plan 9 was finding out that 9p's authentication system works a lot like Kerberos. I am very annoyed by security theater, which is one reason I don't object at all to the host-owner security model Plan 9 uses. — Daniel Lyons
Re: [9fans] a few Q's regarding cpu/auth server
this is silly. the philosophy has been explained. several people have given lots of real world usage where it holds up just fine. i'd go as far as to say the vast majority of plan9 installations are in such environments. but regardless, correcting what may be a whole in your environment is easy; just do so and be done with it.
Re: [9fans] a few Q's regarding cpu/auth server
On Aug 6, 2009, at 6:59 PM, hiro wrote: don't forget to take away the connectors from the power and reset buttons, otherwise good security concepts;) Just out of curiosity, is it possible to simply unbind the console on one of these servers after bootup in some startup script? Or perhaps unbind the keyboard device, so you can see messages but not type anything in? Maybe use cat /dev/kprint instead of rc? It seems like it ought to be possible to disable the physical console this way. I ask simply as a way of reducing worry about passerby, not as a security solution. — Daniel Lyons
Re: [9fans] linux reinvents factotum, secstore ...
These are reasonable questions (and many of them have yes as the answer ;-)) but I have a more fundamental objection here: the desktop is just NOT the place for such a functionality to originate from. The very concept of a fixed desktop that resides on a physical piece of hardware that you own feels so 20th century to me. One way or the other the online identity issue is going to be settled. For contenders, though, I'd rather look at: factotum or things like OAuth. X11 way back when, for all its faults, was more network centric than openview or anything that came after. - erik
Re: [9fans] binary sprint format
j...@plan9.bell-labs.com wrote: the kernel library include file (../port/lib.h) does not have a pragma in it for %b. if this is indeed a kernel driver you are writing then you should add the pragma in the driver: #pragma varargcktypeb int the reason the kernel does not just use libc.h is to catch the inadvertent use of routines from libc.a that just won't work if used in the kernel (e.g. functions that do system calls). if %b becomes commonly used in the kernel and is safe to use (not all format specifiers are safe in the kernel, e.g. those for floating point) then it will find its way into ../port/lib.h. --jim It works perfectly. Thank you very much, Jim. adriano
Re: [9fans] Intel atom motherboard - success at last
On Thu Aug 6 19:36:22 EDT 2009, quans...@quanstro.net wrote: I went through all the default during the install and during fmtfossil I got a few matherror something and it crashed. I t wen too fast for me to take notes. this is due to the awk problem reported this week. i'll roll up another cd this evening. with ide turned off, you probablly just haven't gotten to the part where awk dies. if you can get your machine on the network, you can use /n/sources/contrib/quanstro/awk bind /n/sources/contrib/quanstro/awk /bin/awk i still have to figure out why i can't build a cd after binding awk into a 9660srv fs. well the cd gets built, it's just 20mb too small. - erik
Re: [9fans] a few Q's regarding cpu/auth server
I honestly can't believe that this is even up for debate! grin It's just bizarre. It's not. Nothing stops one from putting the extra layer of security in place, it's just a user-level change, just like it is in Unix to go from single-user to multi-user mode. The fact that no-one has yet found it necessary or worthwhile speaks volumes. If you think it's worth it, then you need to put your money where your mouth is. As for me, I have way too much trouble understanding a hybrid of MIPS and PC architecture to worry about securing equipment no one really seems to want to break into. You are forgetting that the cost of security must be commensurate with the risk. When Plan 9 is popular enough for random visitors to desire to crack it, then the extra security will be worth the extra effort. Until then, we can all save ourselves the bother, including trying to remember different passwords for different hosts. Am I remembering wrong that 2nd Edition had password control on CPU servers? I missed it briefly, then forgot about it. Oh, yes, the change arose from the new security infrastructure, Bell Labs did not have the resources to port it so they abandoned it. I adapted the old password check for something else, but what with NVRAM's failings and the effort involved, I never tried to get the CPU server to have a secured console. ++L PS: Off the cuff, I'd say that adding auth/as to init(8) on a CPU server would be almost all that's needed, just like in Unix. So this discussion has been quite unnecessary.
Re: [9fans] a few Q's regarding cpu/auth server
I have direct experience as a contractor where I have entered many a co-lo; and was unimpressed with their security to say the least. I had constant and easy access to a large number of nameless servers, it's a nobrainer to access keyboard/monitor pairs in many of these places. That would be vandalism. You didn't indulge in it, why would you expect someone else in your situation to do differently? Or are you lying to us? ++L
Re: [9fans] a few Q's regarding cpu/auth server
I honestly can't believe that this is even up for debate! grin It's just bizarre. It's not. Nothing stops one from putting the extra layer of security in place, it's just a user-level change, just like it is in Unix to go from single-user to multi-user mode. The fact that no-one has yet found it necessary or worthwhile speaks volumes. If you think it's worth it, then you need to put your money where your mouth is. As for me, I have way too much trouble understanding a hybrid of MIPS and PC architecture to worry about securing equipment no one really seems to want to break into. You are forgetting that the cost of security must be commensurate with the risk. When Plan 9 is popular enough for random visitors to desire to crack it, then the extra security will be worth the extra effort. Until then, we can all save ourselves the bother, including trying to remember different passwords for different hosts. Am I remembering wrong that 2nd Edition had password control on CPU servers? I missed it briefly, then forgot about it. Oh, yes, the change arose from the new security infrastructure, Bell Labs did not have the resources to port it so they abandoned it. I adapted the old password check for something else, but what with NVRAM's failings and the effort involved, I never tried to get the CPU server to have a secured console. ++L PS: Off the cuff, I'd say that adding auth/as to init(8) on a CPU server would be almost all that's needed, just like in Unix. So this discussion has been quite unnecessary.
Re: [9fans] a few Q's regarding cpu/auth server
On Thursday 06 August 2009 21:19:36 lu...@proxima.alt.za wrote: I have direct experience as a contractor where I have entered many a co-lo; and was unimpressed with their security to say the least. I had constant and easy access to a large number of nameless servers, it's a nobrainer to access keyboard/monitor pairs in many of these places. That would be vandalism. You didn't indulge in it, why would you expect someone else in your situation to do differently? Or are you lying to us? You'll have to do alot better than that if you want to get under my skin. Begone, troll.
Re: [9fans] a few Q's regarding cpu/auth server
On Aug 6, 2009, at 10:19 PM, lu...@proxima.alt.za wrote: I have direct experience as a contractor where I have entered many a co-lo; and was unimpressed with their security to say the least. I had constant and easy access to a large number of nameless servers, it's a nobrainer to access keyboard/monitor pairs in many of these places. That would be vandalism. You didn't indulge in it, why would you expect someone else in your situation to do differently? Or are you lying to us? Story time. :) Several years ago I worked for a company here that had decided to colocate a server locally (yeah, brilliant, in Albuquerque) instead of getting a hosted server somewhere with better access. I wound up going down there a few times to add RAM to the system. Apart from my company, there were a smattering of other smalltimers with big tower computers from Dell on this rack and off on the other side of the facility was a fenced off area with four or five racks of Dell hardware. The owner casually mentioned to me that the company who owned the racks had something to do with airline ticket sales. I guess because I chuckled at that, he also mentioned to me that the computer next to ours was hosting the governor's re-election website. I thought about doing something malicious, because I'm not a big fan of Richardson, but decided it wasn't worth the trouble. Later on one of the owners of the colo facility got bought out and blew up. He went into the facility and ripped out the primary router, then took the upstream cable and plugged it into another port on the backup router such that the packets wound up going in a cycle. Then he damaged the backup power system and flew out the door with the primary router. Not really taking a position here but your comments reminded me of the story. I guess there's always a bigger jerk out there and sometimes he runs your colo facility. — Daniel Lyons
[9fans] the old floppy set
Looking at the very old mailing list archives, I noticed something about a 3-disk (or was it 4-disk?) floppy-based distribution of the earliest PC dist. Is that still available in some form? I just came into possession of a stack of floppies and a pair of 486s and I'm ready to dare to be stupid. John -- Object-oriented design is the roman numerals of computing -- Rob Pike
Re: [9fans] a few Q's regarding cpu/auth server
On Thursday 06 August 2009 21:19:05 lu...@proxima.alt.za wrote: snip If you think it's worth it, then you need to put your money where your mouth is. Like I said: Anyhow... I guess there's no reason to argue/debate! Looks like I have some options ... and later: [...] plus, I've already been provided with solutions from which I can roll my own. You are forgetting that the cost of security must be commensurate with the risk. I'm forgetting what? The Plan 9 way of thinking (wrt the security of physical terminal access) completely undermines, or somehow fails to recognize, the very real fact that there is always a cost/risk effort/reward equation at play. When Plan 9 is popular enough for random visitors to desire to crack it, then the extra security will be worth the extra effort. Until then, we can all save ourselves the bother Sheesh: I think the actual root of the situation, is simply that Plan 9 currently tends to reside within domains with much more strict and secure or trustworthy environments vs. being prevalent within the sphere of the great unwashed masses of the industry where strong physical security is either unobtainable, unaffordable, and/or unreliable at best. Am I remembering wrong that 2nd Edition had password control on CPU servers? I missed it briefly, then forgot about it. Oh, yes, the change arose from the new security infrastructure, Bell Labs did not have the resources to port it so they abandoned it. I adapted the old password check for something else, but what with NVRAM's failings and the effort involved, I never tried to get the CPU server to have a secured console. I mention there are reasonable use-cases for a secured console on Plan 9 servers, and everybody attempts to show me why such a concept is completely unnecessary but in fact it's simply a matter of Bell Labs and others not having the resources to implement it in later editions. And in fact it was a feature that previously existed. PS: Off the cuff, I'd say that adding auth/as to init(8) on a CPU server would be almost all that's needed, just like in Unix. So this discussion has been quite unnecessary. Cool, it's a total no-brainer to implement; the discussion can end now.
Re: [9fans] a few Q's regarding cpu/auth server
On Thu, Aug 6, 2009 at 8:04 PM, Daniel Lyonsfus...@storytotell.org wrote: On Aug 6, 2009, at 6:59 PM, hiro wrote: don't forget to take away the connectors from the power and reset buttons, otherwise good security concepts;) Just out of curiosity, is it possible to simply unbind the console on one of these servers after bootup in some startup script? Or perhaps unbind the keyboard device, so you can see messages but not type anything in? Maybe use cat /dev/kprint instead of rc? It seems like it ought to be possible to disable the physical console this way. I ask simply as a way of reducing worry about passerby, not as a security solution. You should be able to hack /sys/src/cmd/init.c to make it start whatever you want after booting, based on init(8), but I haven't tried it. The man page says it prompts for a password on the cpu server, but that doesn't happen; the source has a pass function but it's not called anywhere. I don't have a real terminal or cpu server at my apartment, so I can't test it right now. John -- Object-oriented design is the roman numerals of computing -- Rob Pike
