On Sat, Apr 29, 2000 at 09:53:51AM +0200, Tomasz Wegrzanowski wrote: > > > > well yes, but only if root is permitted to remove the append only bit, > > in which case the added security is really minimal (ie only protects > > against clueless script kiddies who only know how to edit a log by > > running ./3l337L0ghaX ... > > ./3l337L0ghaX scripts will include append support as soon as using > append bit will spread exactly, which is why immutable/append only bits are really a waste of time unless you use securelevel/capabilities to deny root the ability to remove them, thus giving up log rotation (or rebooting everytime that is required...) security is all about compromises.. > > have it throw away all capabilities other then RAW_SOCKET and > > presumably change uids, throwing away root privileges, better perhaps > > but not as good IMO as never having elevated privileges in the first place. > > why not have : > /dev/rawsocket 660 root.ping > /bin/ping setgid ping there was a idea like that posted to linux-kernel i came accross when reading archives. the idea was to have all the privileged ports (1-1023) as files in /proc or /dev that you could set permissions on like anything else, default being 0600 root.root emulating the standard behavior of only allowing root to use privileged ports. you could then change permissions on them, say /proc/ports/53 to root.named mode 0660, and named would not need to start as root. (not a very good example since named can bind and throw away root nicely) the idea was shot down for some reason, i don't recall exactly why. as for capabilities i really think they should just get it over with and add the filesystem support for them to ext3, along with ACL support (whose space was hijacked to allow for large files). -- Ethan Benson http://www.alaska.net/~erbenson/
Attachment:
pgpaN01GangVn.pgp
Description: PGP signature