Re: protect linux filesystem

["Derek Martin-9" <user=7@nabble.blu.org>]

 On Sat, Jul 26, 2008 at 05:13:05AM -0700, Anil Saini wrote: 
> how to restrict media file to be write or create on linux file system 

The prototypical example of how to do this on Unix systems is syslogd: 
provide a daemon or SUID program that has write access to the file the 
user wants to write, taking the file as input.  This approach has the 
drawback that the program used to police access becomes a potential 
security hole if it is not written well.  Specifically, if the program 
contains a buffer overflow, or other exploitable code, then a user can 
make use of this program to gain access to any system resource which 
that program would normally have access to. 

A possible alternative (with alternative drawbacks) is to use extended 
ACLs.  I say "possible" because I've never actually used them, and I 
tend to think it won't work for reasons I describe below.  You also 
will need to ensure that support for it is compiled into your kernel, 
if I'm not mistaken, which I believe is generally not the case by 
default...  For more info, see the man pages for setfacl and getfacl. 

Using extended ACLs has the often-overlooked drawback that it actually 
greatly complicates access management; widespread use of extended 
ACLs, if not done with great care, could turn managing permissions 
into a small nightmare.  I've seen it happen (though admittedly in a 
different context)... 

The key to restricting a file to be write-only, by (likely) any 
method, is  that you must find a way to allow the user to create the 
file without owning it.  Otherwise, the user can generally just undo 
whatever security measure you used.  For this reason, I think the 
extended ACL method won't actually work, at least not alone.  This 
almost certainly requires some kind of wrapper program.  syslogd 
accomplishes this by running as root (which your program need not, and 
SHOULD not, do) and providing a socket through which programs can 
write data which syslogd will log to the appropriate file. 

In fact, if you were a little crazy, you could actually use syslogd to 
provide this kind of functionality.  The trouble being that it would 
simply continually append any new data logged to whatever file it was 
configured to log into.  It's very unlikely that this is what you 
want. 

But, you can set default ACLs on a directory, which is what you'd need 
to do if you wanted to try to solve this using extended ACLs, assuming 
that the user can't override them for files he owns.  My assumption is 
the opposite, but I have no systems conveniently available where this 
support is enabled, so I can't test it.  I'd be curious about the 
results, if someone did... 

> or also how to limit file size to be created in a particular folder 
> say /tmp folder 

One way is to use logrotate.  This probably doesn't do what you really 
want, but depending on the use case, it might be adequate.  Usually 
logrotate is configured to watch specific files, which may not work 
for your use case.  Then, you initiate logrotate as a cron job 
periodically, which probably also won't work, unless it's OK for the 
configured files to grow beyond the limit you set until the next time 
cron runs logrotate... 

Another possibility is to use ulimit, though this also may not be what 
you really want, since it limits the size of *all* files created by 
child processes of the process where the ulimit was changed.  However, 
it may be useful in conjunction with a wrapper script (which sets the 
ulimit), depending on what you are trying to do. 

Also, Jerry's suggestion is an excellent one.  If /tmp is not already 
its own filesystem, you could make it a separate file system.  Then 
enable quotas on it.  This is probably the best way to get what you 
want, though it probably has the highest learning curve and set-up 
time. 

-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02 
-=-=-=-=- 
This message is posted from an invalid address.  Replying to it will result in 
undeliverable mail due to spam prevention.  Sorry for the inconvenience. 

_______________________________________________ 
Discuss mailing list 
[hidden email] 
http://lists.blu.org/mailman/listinfo/discuss