[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Checksums on ftp



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 ...

the linux appendonly/immutable bits are really more close to BSD's
user append only and user immutable bits (which any user may set
unset on files they own)  


> Yep.  Actually I'm not completely familiar with this yet, I tried to set
> it up on my box but didn't encounter much success because I think I
> didn't correctly compile the caps into the kernel.  There's supposedly
> one or two edits you have to make and the doc I saw wasn't very clear.

im not sure how complete it is, i have tried to play with them yet.

> 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.

> Just don't ask me how yet.  :)

Andrew Morgan (of PAM fame) also wrote a pam module to grant/revoke
capabilities to a user's login.

-- 
Ethan Benson
http://www.alaska.net/~erbenson/

Attachment: pgp15Zwtwh_rM.pgp
Description: PGP signature


Reply to: