Re: good morning to all

2009-06-15 Thread Tim Clewlow

 * malathi selvaraj malathira...@gmail.com wrote:
 i am new one to  freeBSD, kindly guide me

 Sure. In order to be eligible to use FreeBSD, you must buy a license
 for
 $ 100,-. I expect this money to be transferred to my bank account as
 soon as possible. The IBAN number is:

   NL30ABNA0385823426


You may also register at the secret special mailing list
iwannalottaspam.com

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: Simulating bad network conditions

2009-02-18 Thread Tim Clewlow

Here is a link to a mailing list post about a patch to give dummynet
support in pf. It is _fairly_ recent and so may still be a little
buggy, but the poster seems quite confident that it works as
intended.

http://www.mail-archive.com/freebsd...@freebsd.org/msg03857.html

Cheers, Tim.

 On 2009-02-18 11:42:00, Maxim Konovalov wrote:

 ipfw(8) prob + dummynet(8).


 Hi. Thanks for the quick response.

 Is there, by any chance, an equivalent for PF? I see there's 'ALTQ'
 but it looks to be poorly supported (unless I misunderstand). I have
 quite a complicated setup here with PF forwarding and jails and I'm
 not sure how well ipfw will play along.

 thanks,
 xw


___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org


Re: What file on FreeBSD acts like autoexec.bat?

2008-09-28 Thread Tim Clewlow

 What file on FreeBSD acts like autoexec.bat?
 Also please leave the full path%
 ___
 freebsd-hackers@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
 To unsubscribe, send any mail to
 [EMAIL PROTECTED]


From my point of view, I would say that this file acts like an
'autoexec.bat' file, in a highly abstract manner:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/

But I imaging the rc mechanism is more what you are looking for:
http://www.freebsd.org/cgi/man.cgi?query=rcsektion=8

Cheers, Tim.

-- 
The code that never executes at all is the fastest.

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Idea for FreeBSD

2008-08-06 Thread Tim Clewlow

 On Wed, Aug 6, 2008 at 7:14 PM,  [EMAIL PROTECTED] wrote:
 To who it may concern,

   I am A FreeBSD administrator as well as a Solaris Administrator.
 I use
 BSD at home but Solaris at work. I love both OS's but I would like
 to
 increase the administrative capability of FreeBSD.

   In Solaris 10 the Services Management Facility (SMF) was
 introduced.
 Basically what it does, is take all the rc.d scripts and puts them
 into
 a database to manage. Everything is converted to XML

 XML is good at document processing and for portable self-describing
 databases. Otherwise, I would think significantly less of any OS (or
 application) that used XML for configuration data. At least nothing
 that anyone would *every* be forced to edit manually.

 But of course the format of data in a database is largely
 irrelevant.
 You could implement the same thing with dbm files or a more
 forgiving
 text format.

 As for getting rid of rc.d scripts, yes they're decrepit and I would
 love to see them go but they're simple and third party software may
 depend on them being the norm.

 Just my 2c,
 Mike

 PS: I'm not a FreeBSD hacker or even an admin.
 ___

I believe the puppet project has a lot of potential, or if not the
project then at least the ideas behind it, in regard to automating
administrative tasks. I particularly like the way it allows the
automation of the same tasks across different operating systems.

http://reductivelabs.com/trac/puppet/

Cheers, Tim.

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Fwd: Q: case studies about scalable, enterprise-class firewall w/ IPFilter

2008-08-05 Thread Tim Clewlow


 Hello,

 I've posted the attached mail in the IP Filter mailing list; the
 only
 responses have been bad configured vacation replies :-(

 someone from freebsd-hackers has an idea? thanks in advance

   matthias

 - Forwarded message from Matthias Apitz [EMAIL PROTECTED] -

 From: Matthias Apitz [EMAIL PROTECTED]
 Date: Sun, 3 Aug 2008 08:24:15 +0200
 To: IP Filter [EMAIL PROTECTED]
 Subject: Q: case studies about scalable, enterprise-class firewall
 w/ IPFilter


 Hello,

 We're currently protecting our network (and as well some FreeBSD
 laptops
 standalone) with IPFilter... I'm wondering if there are any case
 studies
 about scalable, enterprise-class firewall solutions, redundancy with
 state-full failover, and application-level inspection, and all that
 a
 like, based on IPFilter and FreeBSD;

 thanks in advance for any pointers

   matthias
 --

Hi there, I have never used ipfilter, but I do use pf, and it can do
state-full failover, or firewall redundancy, with CARP (the Common
Address Redundancy Protocol) and pfsync. If there is an equivalent
syncing program, eg ipfiltersync then you could use that with CARP
to allow an ipfilter firewall to fail-over with full state tables
intact.

Also, you can inspect all manner of status info and tables for a
running firewall with pfctl, there must be an equivalent for
ipfilter.

If you are looking for general info about building a firewall, eg
tcp and ip headers, plus icmp and voip and other protocols, then I
would recommend the following tutorial, it has a huge amount of
information - it is a lot more than just a tutorial on iptables.

http://iptables-tutorial.frozentux.net/iptables-tutorial.html

Lastly, the OpenBSD PF Packet Filter Book has been very useful for
me, but I use pf where possible - I think it is the easiest, and
paradoxically the most powerful of all packet filters, but that is
my personal opinion, YMMV.

Cheers, Tim.

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: IPv6 CVS

2008-08-05 Thread Tim Clewlow

 Hi all,

 Does anyone know if there are any IPv6 CVS servers for FreeBSD? (As
 in
 receiving the STABLE and ports branches) I currently use
 cvs.freebsd.org but
 it dosent have an  record.

 Ta

 Peg




 dig  cvsup4.freebsd.org

;  DiG 9.4.2   cvsup4.freebsd.org
;; global options:  printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 34684
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 0

;; QUESTION SECTION:
;cvsup4.freebsd.org.IN  

;; ANSWER SECTION:
cvsup4.freebsd.org. 3600IN  CNAME   freebsd.isc.org.
freebsd.isc.org.3600IN  2001:4f8:0:2::e


___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Postfix problem.

2008-07-14 Thread Tim Clewlow

 Can you please cc: the mailinglist? Thanks.

 -On [20080714 15:36], Andres Chavez ([EMAIL PROTECTED])
 wrote:
postfix/postfix-script: warning: not owned by group maildrop:
 /usr/sbin/
postdrop

postfix/postfix-script: warning: not set-gid or not
 owner+group+world
executable: /usr/sbin/postdrop

postfix/postfix-script: starting the Postfix mail system.

 I would suggest:

 0) clean your system from your botched attempt at installing postfix
 by
yourself
 1) read
 http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports-using.html
 2) install postfix from ports/mail/postfix

 And take it from there?


Hi there,

I have attached the notes I gathered while making the postfix server
that is sending you this mail. In particular, pay attention to the
bit that says:

As part of the installation the port asks if it could add user
postfix to group mail, I advise answering yes. It also offers to
activate postfix in /etc/mail/mailer.conf, again answer yes.

Regards, Tim.

We are BSD ... resistance is futile.
http://www.freebsd.org/ - http://www.openbsd.org/ -
http://www.netbsd.org/

postfix
Description: Binary data
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Sysinstall is still inadequate after all of these years

2008-07-03 Thread Tim Clewlow

 Robert Watson wrote:
 On Thu, 3 Jul 2008, Lothar Braun wrote:

 Robert Watson wrote:

 My primary concern about some of these replacement installer
 projects
 is that they've placed a strong focus on making them graphical
 -- I
 actually couldn't care less about GUIs (and I think they
 actually
 hurt my configurations, since I use serial consoles a lot), but
 what
 I do want is a very tight and efficient install process, which I
 feel
 sysinstall does badly on (not just for the reasons you specify).

 Hmm, how should a tight and efficient installation process look
 like
 in your opinion? And what are the other points that are bad in
 systinstall?

 For me, it's really about minimizing the time to get to a generic
 install from a CD or DVD.  Most of the time, I don't do a lot of
 customization during the install -- I configure machines using
 DHCP, I
 add most packages later, and I tend to use default disk layouts
 since my
 servers don't multi-boot and the defaults currently seem
 reasonable.

 I don't like being asked many more questions than whether or not
 to
 enable sshd, and what to set the root password to.  This means
 that I
 find our current distributions menu a bit inefficient (I don't
 want
 sub-menus, I just want checkboxes), and that the inconsistency in
 the
 handling of the space/enter/tab/cursor keys across different
 libdialog
 interfaces in the install is awkward.  The current generic and
 express
 installs seem to capture a lot of my desire, in that I can get a
 box
 installed in 5m including actual time to write out the file
 systems,
 which is great.  I really don't want to lose this with a new
 installer :-).

 What about having two utilities for the installation process?
 Something
 like a very small (non-gui/non-X) version of sysinstall that just
 installs a base system and only has the functionality to

 - partition/label a disk
 - configure the network (if needed for installation)
 - install the base system (or parts of it)
 - install a boot manager

 and a second utility sysconf that provides the other stuff like
 post
 installation system configuration (sshd, mouse), installing
 packages,
 etc. The second utility could have an X-based GUI without disturbing
 the
 installation process of serial console users or people that don't
 like X
 on their machines.

 Would that be a good idea?

 Best regards,
Lothar

I understand the desire to have an automated installer to make
things real easy for first time installation for new users. But many
people, including myself, will want to retain the current ability to
specify exactly what we want as well. So, why not have a single menu
at the start with 2 options:

1 - automatic desktop install (new user)
2 - traditional installer (veteran user)

Perhaps the automatic installer can just use whatever disk space it
finds (with suitable warnings) and attempt to install everything, ie
equivalent of choosing All at the 'select distributions' stage.
Maybe even do DHCP for net config. This would give a first time user
a working system with a nice shiny X to make them feel good about
choosing FreeBSD.

Yes, I know they could just go to pcbsd, but I would prefer to have
a new user at least attempt to learn proper sysadmin skills on
vanilla FreeBSD. And if a new user gives up just because the
installer is too confusing (especially the partitioner - it is
wonderfully powerful, but it does take a bit of getting used to)
then I think that is a shame.

My adjust for current exchange rate cents.

Tim.

This email has been checked for viruses. It has sufficient.

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


ICANN votes to expand domain name character set

2008-06-26 Thread Tim Clewlow
Hi there,

In case you haven't heard yet, ICANN have unanimously voted their
approval to expand the domain name character set to include Asian,
Middle Eastern, Eastern European and Russian character sets in
domain names. In addition, top level domains will have their
restrictions removed, ie any non-offensive top level domains will
now be allowed.

I'm guessing the inclusion of the new character sets will mean a
fair amount of alteration to code that processes domain names.

http://www.icann.org/en/announcements/announcement-4-26jun08-en.htm

Cheers, Tim.

We are BSD ... resistance is futile.
http://www.freebsd.org/ - http://www.openbsd.org/ -
http://www.netbsd.org/

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


PXE on 7.0 problem and solution

2008-02-28 Thread Tim Clewlow
Hi there,

Installing 7.0 via PXE has a slight problem that is easily worked around. The
file /boot/mfsroot.gz on the installation media needs to be unzipped to make
PXE boot via tftp/nfs work. Otherwise the loader ultimately complains that it
cant find the device to boot from. For example, if you have the installation
media living at /usr/pxe/nfs/ on the PXE server, then do:

gzip -d /usr/pxe/nfs/boot/mfsroot.gz

After doing this it now loads the kernel and starts the installation procedure
as expected. Someone more knowledgeable than me might want to let whoever needs
to know about this.

Apart from that, it looks great, the work is appreciated, thanks for the new
release :-)

Cheers, Tim.

We are BSD ... resistance is futile.
http://www.freebsd.org/ - http://www.openbsd.org/ - http://www.netbsd.org/


  

Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  
http://tools.search.yahoo.com/newsearch/category.php?category=shopping
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Security Flaw in Popular Disk Encryption Technologies

2008-02-23 Thread Tim Clewlow

--- Pieter de Boer [EMAIL PROTECTED] wrote:

 Jeremy Chadwick wrote:
 
  It's interesting that you classified this as a feature (in quotes),
  because there's nothing modern about said feature.  This issue has
  existed since the beginning of RAM chip engineering; I can even confirm
  this feature exists on old video game consoles such as the Nintendo
  and Super Nintendo (where there were strict guidelines put in place by
  Nintendo, requiring developers to initialise certain areas of memory
  and certain memory-mapped I/O registers during hard or soft resets).
 I shouldnt've used the word 'modern', then.
 
  Proper software should be memset() or bzero()'ing memory space it
  mallocs.  I've gotten in the habit of doing this for years, purely as a
  safety net.  If said software doesn't do this, it's very likely
  succeptable.
 That is not relevant to the issue. The issue is that the keys are in 
 memory when the encrypted filesystem is in use. The keys can be read by 
 pulling and reinserting the power plug and restarting into a tool that 
 can dump memory (or by placing the memory modules in another system). 
 The keys to encrypted volumes can be found in this dump, leading to a 
 compromise of the data.

Many BIOS have fast and slow boot options - they are usually set to fast by
default. The slow boot option often checks RAM and effectively wipes RAM in the
process. If the BIOS is password protected then the only way to break in is to
reset the BIOS by removing the BIOS battery. Given that RAM degrades over a
short period of no power, and that arranging to physically pull the BIOS
battery most likely exceeds that time limit, then this would effectively be one
solution. Although it will mean always booting the slow way.

Tim.


  

Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Security Flaw in Popular Disk Encryption Technologies

2008-02-23 Thread Tim Clewlow

--- Dimitry Andric [EMAIL PROTECTED] wrote:

 On 2008-02-23 02:08, Atom Smasher wrote:
  article below. does anyone know how this affects eli/geli?
  
  from the geli man page: detach - Detach the given providers, which means 
  remove the devfs entry and clear the keys from memory. does that mean 
  that geli properly wipes keys from RAM when a laptop is turned off?
 
 This is a physical attack, and there's nothing you can do in software to
 prevent it.  Of course geli or other software can attempt to erase the
 keys from RAM as soon as it's done using them, but it won't prevent
 hijacking them beforehand.
 
 It's the same with all physical attacks: hardware sniffers, keyloggers,
 TEMPEST, etc.  You need physical (hardware) protection to secure
 against these, not software.

The cracking method relies on the ability to find the key in memory, so, if the
key is obfuscated then this would mean the cracking method could no longer find
the key even if it has access to memory. For example, create a series of random
bytes of equal length to the key, lets call that the obfuscator. And now xor
that with the key, lets call that the xord key. To use the enc/dec system an
extra step would need to xor back to the original key.

The idea is that real key is only created when needed for use, and then
immediately overwritten after use. If the obfuscator and the xord key are
stored in memory at unpredictable locations, ie dont just have them sitting
next to each other, then this would make it much more difficult to _find_ the
key as it would now involve identifying two groups of randomly located (in
memory) bytes that are xor'd to create the real key.

Yes, with sufficient reverse engineering it would be possible to find out where
the obfuscator and xord key have been stored, but this would at least stop
the relatively trivial search method being used in the paper.

Just a thought, and yes, I have now actually read the paper.

Tim.


  

Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: firefox flash plug in woes

2008-01-25 Thread Tim Clewlow

--- KAYVEN  RIESE [EMAIL PROTECTED] wrote:

 
 i have been told that freeBSD does not go well with
 flash plugins for browsers, which is quite a ubiquitous
 technology in websites.  is there any progress on this?
 i have freeBSD 6.2-STABLE and gnome desktop
 

Hi there, I have native firefox with flash 7 working fine on FreeBSD 6.2, with
java and adobe reader. Note I always install via ports, and they are up to
date.  Anyway, here is how, you can try it from packages, ie pkg_add -r x -
hopefully that works too, but if it doesnt then installing from ports
definately does.

[ Note, I just copies/pasted this from my notes, there may be later versions of
these packages you can also use - but IIRC I had some problems with them ]

install www/firefox   
install print/acroread7   
install java/diablo-jdk15
install www/linux-flashplugin7   
kldload linux
echo none/compat/linux/proc  linprocfs   rw  0  
0  /etc/fstab
mount -a
echo linux_enable=\YES\  /etc/rc.conf   
nspluginwrapper -v -a -i

Cheers, Tim.

We are BSD ... resistance is futile.
http://www.freebsd.org/ - http://www.openbsd.org/ - http://www.netbsd.org/


  

Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  
http://tools.search.yahoo.com/newsearch/category.php?category=shopping
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Project Ideas and a question

2007-10-14 Thread Tim Clewlow

--- David Naylor [EMAIL PROTECTED] wrote:

 Hi,
 
 The question first: init does allow a chroot before booting the system
 however 
 does it allow the first device to be unmounted and use the new chroot as the 
 root device.  If it does how can that be achieved.  
 
 My motivation for this: Allow a USB device or CDROM to boot the system, then 
 init running of the removable device to execute a script that will allow the 
 system to be setup (such as configure devices, setup gdbe and geli, etc) then
 
 when init chroot's it unmounts the removable device and allows that device to
 
 be physically removed.  
 
 I have some project ideas (due to lack of technical skills I can not pursue 
 them at this time but that is no reason not to share :-).  If someone thinks 
 an idea is a good one could you please add it to the appropriate location 
 (the volunteer projects page???).  My ideas:
 
 1) Automatic module loading.  Create a discovery system that upon identifying
 
 hardware that a module supports, loads the module.  This would probably be a 
 user-land implementation? 
   Motivation: Additional ease of use (especially with sound)
 
 2) Automatic kernel customisation.  A tool that builds a custom kernel with 
 all the devices for the current system builtin and with everything not needed
 
 removed.  
   Motivation: Take the hard work out of building a custom kernel]
 
 3) If question above is not implemented than add to idea list...
 
 Feedback is welcome.  Thank you for listening to me.  
 
 David

Hello David,

These all sound like great ideas, however they may have a better chance of
being implemented on one of the sibling versions of FreeBSD, ie Desktop BSD
or PC BSD. These offerings have already made quite large steps in regard to
automating the installation of a BSD system. The general aim is to make it as
easy as possible for someone unfamiliar with BSD to install a desktop, ie so it
can compete with other desktop operating systems that are already very easy to
install.

By contrast, the native version of FreeBSD is put to many uses, often not
involving a desktop, eg servers, routers, embedded systems. The ability to
customize/tune pretty much all of the kernel/world is what makes this possible.
And so having an automated installation would have to be unbelievably
intelligent, and complicated, in order to cater for all these possibilities.

Lastly, keep going with the new ideas, they are always welcome. Perhaps you may
 want to send them to [EMAIL PROTECTED] as this would seem to be more
appropriate for initial ideas postings - and more people will see them as well
:-)

Kind Regards, Tim.


  

Tonight's top picks. What will you watch tonight? Preview the hottest shows on 
Yahoo! TV.
http://tv.yahoo.com/ 

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: MS Vista vs FreeBSD's bootloader

2007-06-29 Thread Tim Clewlow

--- Thomas Sparrevohn [EMAIL PROTECTED] wrote:

 On Thursday 28 June 2007 14:44:05 [EMAIL PROTECTED] wrote:
  
  --- Thomas Sparrevohn [EMAIL PROTECTED] ha scritto:
  ...
  
   
   I have Vista Home edition ruinning any FreeBSD without any problems  and
   without having to do anything special - That is on CURRENT 
   
   
  Hmm...
  
  Installation order is important, perhaps you already had FreeBSD before
  installing Vista? In my case Vista Premium came preinstalled, there was
 also a
  FAT partition (with diagnostic stuff) and an NTFS for rescue purposes.
  
 
 No - The originally came with XP - I nuked that and installed FreeBSD -
 However 
 I did nuke the XP totally before upgrading to Vista - It does overwrite the
 FreeBSD
 MBR  - I just rebooted using a CD and added the mbr again
 
  Of course getting the new computer without Vista was not really an option
 :(,
  but MS went too far this time, they removed postcript type1 font support
 and
  they crippled OpenGL enough that major CAD packages don't work easily or
 have
  something like 85% performance penalty. 
  
  Pedro.
  

---

Hi, this may not be the correct place to ask - but it is related. Has anyone
been able to get Vista running on qemu?

Cheers, Tim.


   

Be a better Globetrotter. Get better travel answers from someone who knows. 
Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=listsid=396545469
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: [patch] rm can have undesired side-effects

2006-10-31 Thread Tim Clewlow


--- Daniel Valencia [EMAIL PROTECTED] wrote:

 Actually, I would like to support this motion...
 Thinking over the possible behaviours of -P is to
 sit in a room saying to delete or not to delete...
  If you think it over from a higher perspective,
 The UNIX Way (TM) is to have individual commands
 for specific tasks and to extract tasks from
 commands that have gotten too complex... and I think
 this is the case of rm...  a shred command should
 be added that has the following behaviour:
 
 if the file is not writable, return with error.
 if the file has multiple links, and option -f was
 not specified, return with error.
 overwrite the file.
 optionally, unlink the file.
 
 Additionally, -P should either be rm'ed from rm, or
 added as a backwards compatibility hack that calls
 shred and returns with error every time the latter
 does.
 
 These are my 1.99 cents.
 
 
 - Daniel
 
 
 - Original Message 
 From: Tim Clewlow [EMAIL PROTECTED]
 To: Bakul Shah [EMAIL PROTECTED]; Doug Barton
 [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
 freebsd-hackers@freebsd.org
 Sent: Monday, October 30, 2006 12:20:33 PM
 Subject: Re: [patch] rm can have undesired
 side-effects
 
 
 --- Bakul Shah [EMAIL PROTECTED] wrote:
 
  Sorry if I tuned in late:-)
  
  I vote for taking *out* -P.  It is an ill-designed
  feature.
  Or if you keep it, also add it to mv, cp -f  ln
 -f
  since
  these commands can also unlink a file and once
  unlinked in
  this matter you can't scrub it.  And also fix up
 the
  behavior
  for -P when multiple links.  And since mv can use
  rename(2),
  you will have to also dirty up the kernel
 interface
  somehow.
  Not to mention even editing such a sensitive file
  can leave
  stuff all over the disk that a bad guy can get at.
 
  If you
  are truely paranoid (as opposed to paranoid only
  when on
  meds) you know how bad that is!
  
  If you are that concious about scrubbing why not
 add
  scrubbing as a mount option (suggested option: -o
  paranoid)
  then at least it will be handled consistently.
  
  What's the world come to when even the paranoid
 are
  such
  amateurs.
  
  -- bakul
  
 
 Based on all the potential situations where a -P
 option may possibly be implemented, is it worthwhile
 considering creating a command that just scrubs a
 file, and does nothing else. This would seem to fit
 the Unix paradigm of single command to do a single
 thing, and may be preferable to attempting to embed
 this function in every command that may possibly
 remove a file.
 
 Just my 2c
 
 Tim
 

Having thought this over some more, if a
shred/scramble/scrub command is created in its own
right, then a number of new features could be added
that do not currently exist.

- The command could be writen to protect a single
file, or, it could also write to an entire file
system/media.

- The command could offer many types of randomising
possiblities, eg the current 0xff, 0x00, 0xff; or
perhaps /dev/random could be written; or perhaps the
user could specify exactly what is to be used to
overwrite the file/file system - from memory some
large organistations (govt depts) have specific rules
about how files/file systems should be overwritten
before old medie is thrown out and replaced (so no-one
can scavenge the media and read sensitive data)

Kind of thinking out loud here, apologies if its
noisy, Tim.



 

Everyone is raving about the all-new Yahoo! Mail 
(http://advision.webevents.yahoo.com/mailbeta/)

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: [patch] rm can have undesired side-effects

2006-10-31 Thread Tim Clewlow


--- Bakul Shah [EMAIL PROTECTED] wrote:

  Having thought this over some more, if a
  shred/scramble/scrub command is created in its own
  right, then a number of new features could be
 added
  that do not currently exist.
 
  - The command could be writen to protect a single
  file, or, it could also write to an entire file
  system/media.
 
 These won't share much beyond what patterns to write
 and how many times.
 
  - The command could offer many types of
 randomising
  possiblities, eg the current 0xff, 0x00, 0xff; or
  perhaps /dev/random could be written; or perhaps
 the
  user could specify exactly what is to be used to
  overwrite the file/file system - from memory some
  large organistations (govt depts) have specific
 rules
  about how files/file systems should be overwritten
  before old medie is thrown out and replaced (so
 no-one
  can scavenge the media and read sensitive data)
 
 IMHO even this does not address paranoia very well. 
 The
 point of rm -P is to make sure freed blocks on the
 disk don't
 have any useful information.  But if the bad guy can
 read the
 disk *while* it also holds other files on it, the
 battle is
 already lost as presumably he can also read data in
 live
 files.  If you are using rm -P in preparation to
 throwing a
 disk away, you may as well just use a whole disk
 scrubber.
 If you are using rm -P to prevent a nosy admin to
 look at
 your sensitive data, you will likely lose.  He can
 easily
 replace rm with his own command.  A separate scrub
 command
 may help since you can verify the data is erased.
 
 This is not to say rm -P or scrub is not helpful. 
 If you
 know what you are doing it is perfectly adequate. 
 But if you
 don't or you make mistakes, it will give you a false
 sense of
 security.  For example, once a file is unlinked
 through some
 other means (such as mv) you don't have a handle on
 it any
 more to scrub.  Basically you lost the ability to
 scrub your
 data due to a mistake.  Worse, editing such a file
 may free
 unscrubbed blocks.  A separate command won't help.
 
 This is why I suggested to have the system do this
 for you
 (through a mount option -- I don't care enough to
 want to
 implement it).
 
  Kind of thinking out loud here, apologies if its
  noisy, Tim.
 
 If the end result is clear headed go right ahead!
 

Having cleared my head a bit more, I realise most of
this can be done with consecutive runs of 'dd'.
I think I've reached a conclusion here.

Tim.



 

Low, Low, Low Rates! Check out Yahoo! Messenger's cheap PC-to-Phone call rates 
(http://voice.yahoo.com)

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: [patch] rm can have undesired side-effects

2006-10-30 Thread Tim Clewlow


--- Bakul Shah [EMAIL PROTECTED] wrote:

 Sorry if I tuned in late:-)
 
 I vote for taking *out* -P.  It is an ill-designed
 feature.
 Or if you keep it, also add it to mv, cp -f  ln -f
 since
 these commands can also unlink a file and once
 unlinked in
 this matter you can't scrub it.  And also fix up the
 behavior
 for -P when multiple links.  And since mv can use
 rename(2),
 you will have to also dirty up the kernel interface
 somehow.
 Not to mention even editing such a sensitive file
 can leave
 stuff all over the disk that a bad guy can get at. 
 If you
 are truely paranoid (as opposed to paranoid only
 when on
 meds) you know how bad that is!
 
 If you are that concious about scrubbing why not add
 scrubbing as a mount option (suggested option: -o
 paranoid)
 then at least it will be handled consistently.
 
 What's the world come to when even the paranoid are
 such
 amateurs.
 
 -- bakul
 

Based on all the potential situations where a -P
option may possibly be implemented, is it worthwhile
considering creating a command that just scrubs a
file, and does nothing else. This would seem to fit
the Unix paradigm of single command to do a single
thing, and may be preferable to attempting to embed
this function in every command that may possibly
remove a file.

Just my 2c

Tim


 

Low, Low, Low Rates! Check out Yahoo! Messenger's cheap PC-to-Phone call rates 
(http://voice.yahoo.com)

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]