Prev: JOB Opening: Urgent required System software Engineers Exp:2-4years
Next: How to avoid the spam on this news group?
From: David Schwartz on 10 Nov 2009 23:35
On Nov 9, 7:47 pm, "lovecreatesbea...(a)gmai1.c0m"
<lovecreatesbea...(a)gmail.com> wrote:

> 1. system accounts including root can't directly access file or data
> on this system;
[snip]
> Is there conceptual wrong in this requirement?
> Can it be done in way of linux kernel file system, ie. ext2, ext3?
> How to program this kind of customized file system?

Linux is not the right operating system for meeting requirements like
these. Linux is fundamentally built around a "root can do anything"
model.

However, I think this sounds like a nonsensical set of requirements.
What would the rationale for requirement 1 be? To prevent root from
deliberately causing problems? But he'll just do things indirectly, so
stopping him from doing things directly makes little sense. To prevent
him from accidentally accessing file or data? What does "directly"
even mean in this context?

DS
From: Rainer Weikusat on 11 Nov 2009 07:51
David Schwartz <davids(a)webmaster.com> writes:
> On Nov 9, 7:47�pm, "lovecreatesbea...(a)gmai1.c0m"
> <lovecreatesbea...(a)gmail.com> wrote:
>
>> 1. system accounts including root can't directly access file or data
>> on this system;
> [snip]
>> Is there conceptual wrong in this requirement?
>> Can it be done in way of linux kernel file system, ie. ext2, ext3?
>> How to program this kind of customized file system?
>
> Linux is not the right operating system for meeting requirements like
> these. Linux is fundamentally built around a "root can do anything"
> model.

This is not correct. The traditional UNIX(*) security model includes
the notion of a superuser which has unrestricted access to
everything. Insofar particular privileged operations are supposed to
be made available to otherwise unprivileged users, this policy
descision is supposed to be implemented in application code. This is a
simple and unlimitedly flexible model which has been proven to be
sufficient for many real-world applications. It, howevers, suffers
from two important drawbacks:

- the TCB (trusted computing base) is extended to application
code, which is a very ill fit for 'the hack on it until it
works, although nobody knows how or why, and then move one
to the next problem' common development paradigm.

- it is simple. People who desire 'security' are likely to
have a bureaucratic mindset and 'simplictly' is inherently
un-bureaucratic.

Therefore, the 'Linux' security model is built around an ever growing
set of 'capabilites', ie particular tasks someone considers to be
'special' for some more-or-less random reason and which can be revoked
and granted to entities scheduled by the kernel ('threads' and
single-threaded processes) by using the corresponding system calls
according to a fairly elaborate model[*]. Details are documented in
capabilities(7), an online copy is available here:

http://www.kernel.org/doc/man-pages/online/pages/man7/capabilities.7.html

According to the documentation, it should be possible to meet the file
access requirement in this way. Another option would be to use
mandatory access control, ie SELinux (AppArmor loses another big set
of points because of people who try to play games with Wikipedia).

[*] So far, the most notable achievement of this 'new and
improved design' have been 'new and moderately interesting
ways to accomplish privilege escalation'.

From: lovecreatesbeauty on 13 Nov 2009 02:23
On Nov 11, 9:44 am, "lovecreatesbea...(a)gmai1.c0m"
<lovecreatesbea...(a)gmail.com> wrote:
> On Nov 10, 6:26 pm, Edwin van den Oetelaar <newsgro...(a)oetelaar.com>
> wrote:
>
> > lovecreatesbea...(a)gmai1.c0m wrote:
> > > I encountered such an requirement of implementing a system that:
>
> > > 1. system accounts including root can't directly access file or data
> > > on this system;
>
> > That would be strange.
> > You could use a userspace application that does encrypting/decrypting of files on disk.
> > This way, the root user can read the *file* but not decrypt its *contents* (data). Deleting the file
> > is still possible.
>
> Thank you.
>
> I proposed ccrypt for it but it was not adopted.
>
> > > 2. only specific application, ie. http server (apache) can access file
> > > on this system; (so apache linux user ie. www-data should be allowed
> > > on it)
>
> > If you do your encryption/decryption/authentication inside the application that would work.
>
> > > 3. apache passes web user accounts (not linux system account ie. root)
> > > to this system; and this system will present the apache application
> > > with the files (in format of linux file system hierarchy) related to
> > > the specified web users;
>
> > Does not compute, but take a look at FUSE, maybe filesystems in UserSpace help you.
>
> Fuse faq 1.5[1] states a situation that users including root can't
> access filesystems mounted by other users. I tried fuse example
> hello.c. Other problem is that I don't figure out
>
> how to make files in fuse persistent to physical media? or
> how to map (mount?) fuse with a existing file system? or
> how to format a fuse file system to physical media (we can format ext3
> but not fuse)?
>
> > > And I have some queries about it:
>
> > > Is there conceptual wrong in this requirement?
>
> > I think so. Instead of making the whole system more secure it introduces a lot of complexity that
> > can break in unexpected ways. If you use normal setup with *sane* security setup it would be easier
> > to setup and maintain.
>
> > > Can it be done in way of linux kernel file system, ie. ext2, ext3?
> > > How to program this kind of customized file system?
>
> > Where / Why is this strange setup required? Is the rest of the system as secure? SSH/Certificates etc?
>
> I am supervised by an amateurish supervisor and I myself am not
> professional enough to convey all the plans and ideas to correct
> solutions on linux with C quickly enough. It seems that I / We are
> doing some fake projects.
>
> [1]http://sourceforge.net/apps/mediawiki/fuse/index.php?title=FAQ#Why_do...


I add some code in vfs. For example, it allows apache to access /var/
www but prevents root user from accessing /var/www/index.html by vi.
My supervisor prefers this kind of solution. But I am a little upset
on rough change like this.


--- a\linux-2.6.30.4\fs\open.c 2009-07-31 06:34:48.000000000 +-0800
+++ b\linux-2.6.30.4\fs\open.c 2009-11-13 14:34:45.000000000 +-0800
@@ -1026,12 +1026,20 @@
EXPORT_SYMBOL(fd_install);

long do_sys_open(int dfd, const char __user *filename, int flags, int
mode)
{
char *tmp = getname(filename);
int fd = PTR_ERR(tmp);
+ char *s1 = "/var/www";
+ char *s2 = "apache2";
+
+ if (strstr(filename, s1) && strcmp(s2, current->comm)){
+ printk("%s:%d, %s, %s\n", __FILE__, __LINE__,
+ current->comm, filename);
+ return fd;
+ }

if (!IS_ERR(tmp)) {
fd = get_unused_fd_flags(flags);
if (fd >= 0) {
struct file *f = do_filp_open(dfd, tmp, flags, mode, 0);
if (IS_ERR(f)) {
From: Rainer Weikusat on 13 Nov 2009 05:49
"lovecreatesbeauty(a)gmai1.c0m" <lovecreatesbeauty(a)gmail.com> writes:

[...]

> I add some code in vfs. For example, it allows apache to access /var/
> www but prevents root user from accessing /var/www/index.html by vi.
> My supervisor prefers this kind of solution. But I am a little upset
> on rough change like this.
>
>
> --- a\linux-2.6.30.4\fs\open.c 2009-07-31 06:34:48.000000000 +-0800
> +++ b\linux-2.6.30.4\fs\open.c 2009-11-13 14:34:45.000000000 +-0800
> @@ -1026,12 +1026,20 @@
> EXPORT_SYMBOL(fd_install);
>
> long do_sys_open(int dfd, const char __user *filename, int flags, int
> mode)
> {
> char *tmp = getname(filename);
> int fd = PTR_ERR(tmp);
> + char *s1 = "/var/www";
> + char *s2 = "apache2";
> +
> + if (strstr(filename, s1) && strcmp(s2, current->comm)){
> + printk("%s:%d, %s, %s\n", __FILE__, __LINE__,
> + current->comm, filename);
> + return fd;
> + }

The most glaring problem with this is that this will (probably, I
haven't tested it) allow access to any process whose corresponding
binary is named apache2. Try

cd /bin
ln ed apache2
../apache2 /var/www/index.html

as root for a demonstration (assuming /bin/ed exists, of course).

You really should be using the existing facilities for extended access
control, such as capabilities or one of the MAC-frameworks instead of
trying to 'roll your own' in a that crude fashion.
From: Gordon Burditt on 13 Nov 2009 12:13
>> I add some code in vfs. For example, it allows apache to access /var/
>> www but prevents root user from accessing /var/www/index.html by vi.

So what prevents root from using su to apache? What prevents root
from replacing apache with vi (while the real apache is still running)?
What prevents root from taking that code out of the kernel?


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: JOB Opening: Urgent required System software Engineers Exp:2-4years
Next: How to avoid the spam on this news group?