lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e024ccca0609161801y68ba924cqbc7e39a3379c5ad@mail.gmail.com>
Date: Sat, 16 Sep 2006 21:01:51 -0400
From: "Dude VanWinkle" <dudevanwinkle@...il.com>
To: "Dean Pierce" <piercede@....edu>
Cc: full-disclosure <full-disclosure@...ts.grok.org.uk>
Subject: Re: AFS - The Ultimate Sulution? -- What is the
	point?

why not just use a dumb terminal if you are going to go to all that trouble?

-JP

On 9/15/06, Dean Pierce <piercede@....edu> wrote:
> There is the convenience issue of the speed that the image transfers
> across the network.
>
> There is also the issue that infected workstations may be collecting
> passwords.
>
> My suggestion would be to use the harddrives in the workstation to store
> the boot images, and have the minimal operating system on some sort of
> USB device or something that the employees can take home with them, and
> carry around etc.
>
> The employee can then..
>
>  1. plug in the USB device
>  2. boot the machine
>  3. enter device password (to decrypt the rest of the device)
>  4. the USB device should then be removed
>  5. enter the network username and password (remote authentication)
>  6. select which operating system to boot to
>     - now the system checks the hash of the selected image,
>       and submits it to a central server for approval
>     - if image is approved, the system is booted
>     - network mounts are mounted based on user policy etc
>
> Workstations would then need to be locked down, allowed only to ever
> boot to the USB device or whatever, and might employ some bios tricks to
> only boot devices that have been signed etc. A decent chassis alarm
> system would also need to be in place to avoid tampering.  Network
> topology should also be static, and trigger alarms if anything is changed.
>
> It would then be up to the sysadmins to keep the images up to date (not
> just security-wise, but also with the latest software).
>
> If the employee is working with sensitive information (that the
> sysadmins should not have access to), the data should all be stored in
> an encrypted state on the remote filesystems, and decrypted on the fly
> on the workstation when needed.
>
> problems that may still exist:
>
> 1. weak sysadmin security policies
> 2. weak add/remove/refresh user policies
> 3. weakness in the encryption protocols
> 4. USB devices can be cloned
>
> 1 and 2 can be mitigated with strict rules and a positive work
> environment, and proactive education (preventing bribes/social
> engineering etc).  3 is the fault of the cryptanalysts, and 4 can be
> dealt with by using devices with non-readable sections and on-board
> crypto (like a smartcard etc).
>
> Different things can be enforced more or less based on paranoia levels,
> but I would say this system is reasonably simple, and prevents most
> nastiness, and could even remain pretty stable if the images were not
> updated frequently.  With using old images, there is the chance of worms
>  infecting the workstation in the morning, but a decent IPS should
> prevent that, and it would be much easier to clean up later.
>
> Also employees might use recent attacks against eachother to gain
> information on other employees that they do not have access to.  IPS
> should see this though, and if you are really worried, you can make it
> so all writable directories that a user has are mounted without execute
> permissions or something.
>
> The user experience is not much more complicated than most current
> setups, and I believe this does go pretty far to protect the
> workstations from pretty much any sort of malicious tampering, which was
> the goal I think.
>
>    - DEAN
>
>
> マグロ原子 wrote:
> > In-Reply-To: <4509C2FE.8020104@...erved.de>
> >
> > I don't really see the point... Possible vulnerabilities (if I didn't
> > horribly misunderstand something):
> >
> > *The AFS server would still need to be updated to keep it secure.
> > *If the imaged OS is rootable:
> > **The AFS clients that load the images could be replaced by phishnets.
> > **The attacker could pose as the user having access to Kerberos
> > credentials. (So rm -r / would delete the users "securely kept files")
> >
> > Or do users only have read-only access to their files?? That doesn't
> > seem useful.
> >
> > Nyoro~n
> >
> > _______________________________________________
> > Full-Disclosure - We believe in it.
> > Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> > Hosted and sponsored by Secunia - http://secunia.com/
> >
>
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
>
>

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ