On Thu, Apr 27, 2000 at 06:13:31PM -0800, Ethan Benson wrote: > > On Fri, Apr 28, 2000 at 02:03:07AM +0000, Jim Breton wrote: > > On Thu, Apr 27, 2000 at 05:35:42PM -0800, Ethan Benson wrote: > > > why zap an immutable log file? it won't contain any new entries since > > > syslogd cannot write to it either :P you probably mean the append > > > only bit. which is indeed useful on logs but breaks log rotation > > > which is rather annoying. > > > > Yup I did mean append-only. You could always mix a chattr -a, chattr +a > > into your log rotation scripts to work around that. > > 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 > > But from what I've seen so far, I do believe you would be able to > > somehow add capabilities to a running process (as well as remove them). > > yes that is indeed possible, though what im more interested in is > being able to set capabilities on a binary in the filesystem instead > of making it SUID root. so instead of suid root /bin/ping you would > have a non suid /bin/ping with the CAP_RAW_SOCKET (or whatever its > called) capabilty set. but this requires filesystem support that we > don't have yet. the alternative is still having suid root ping but > 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
