Re: Checksums on ftp
The securelevel is obsolete, which is probably why it doesn't seem to be
there anymore. Check out the 'lcap' package: once you remove one of the
capabilities in that list, it cannot be restored until the machine is
rebooted, and you'd probably have to boot into single user mode in order
for it to not automatically remove those capabilities again.
The CAP_NET_ADMIN capability, by the way, affects the following:
- interface configuration is disabled. (yes, this means DHCP clients and
dialups will break)
- firewall, masq, accounting changes are disabled.
- can't set debug option on sockets.
- can't change routing tables, which also breaks DHCP/dialup.
- can't set arbitrary process (group) ownership on sockets.
- can't bind to any address for transproxy.
- can't set TOS.
- can't set promiscuous mode.
- can't clear driver stats.
- can't multicast. (!)
- can't read/write device-specific registers.
EFD1 AC6C 7ED5 E453 C367 AC7A B474 16E0 758D 7ED9
-----BEGIN GEEK CODE BLOCK-----
GCM d- s:+ a--- C++++ UL++++ P L+++ E W++ N o-- K- w
O--- M- V- PS+ PE- Y PGP t+ 5 X- R tv+ b DI--- D+
G e-- h++ r--- y
------END GEEK CODE BLOCK------
On Thu, 27 Apr 2000, Ethan Benson wrote:
> On Thu, Apr 27, 2000 at 10:58:54AM +0200, L. Besselink wrote:
> > On Wed, 26 Apr 2000, Ethan Benson wrote:
> > >
> > > so why don't we use sha1 or rmd160 or all three like OpenBSD ;-)
> > >
> > > lets see you break those ;-)
> > >
> > > --
> > > Ethan Benson
> > > http://www.alaska.net/~erbenson/
> > >
> > I think the system OpenBSD uses is great, I think we should combine:
> > dpkg, apt and aide (the just added to unstable intruder detection system,
> > includes checking on conf and binaries).
> > The system would work like this:
> > apt-get install package
> > check md5 and others inculded in the file or in seperate files that where
> > on the ftp/http site.
> > check if aide is installed, if so:
> > check if the files that needs to be installed are in the
> > directories that need to be checked by aide, if so make md5 and
> > others. Then install the file.
> > (and ofcourse make medium on which database exists readonly again, by
> > hardware).
> this last one is tricky, the databases are probably too large for
> floppies, and floppies tend to go bad rather fast if you use them
> alot. hard disks sometimes have a read-only jumper but you would have
> to reboot and open the case every time you wanted to apt-get
> install/dist-upgrade something. one neat way would be a CD-RW, have
> both an ordinary CDROM and a CD-RW drive, when you upgrade or install
> something move the checksums cd-rw to the RW drive, update it then
> take it out and put it back in the CDROM drive. theres no modifying a
> CD-r[w] from a CDROM drive. this system would break down on remotely
> administered systems however.
> OpenBSD (and probably the other BSDs too) also have kernel
> securlevels that can be useful in protecting this kind of stuff, once
> you raise the securelevel to 1 on OpenBSD (as is done by default at
> boot) the superuser may not remove the system immutable bit from any
> file, and device files corrasponding to mounted filesystems may no be
> accessed (or maybe just written..). securelevel 2 gets more draconian
> where no device files at all may be written (and possibly read)
> firewall rules may not be rewritten and a few other things i don't
> remember. the immutablity is nice but you have to reboot into single
> user mode to remove the immutability and update the immutable file,
> which is rather inconvenient...
> this contrasts with linux's immutable bit that the superuser may
> remove whenever he wants, making it mostly pointless. (i read
> somewhere that someone added a securelevel to linux, but i dont recall
> > And no I can't code. :(
> > Leen.
> me neither, at least not in C ;-)
> Ethan Benson