Prev: JOB Opening: Urgent required System software Engineers Exp:2-4years
Next: How to avoid the spam on this news group?
From: lovecreatesbeauty on 9 Nov 2009 22:47
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;
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)
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;


And I have some queries about it:

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?

Thank you for your time.
From: Edwin van den Oetelaar on 10 Nov 2009 05:26
lovecreatesbeauty(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.

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

>
> 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?
>
> Thank you for your time.

Where / Why is this strange setup required? Is the rest of the system as secure? SSH/Certificates etc?

Regards,
Edwin
From: Dagon on 10 Nov 2009 15:00
>lovecreatesbeauty(a)gmai1.c0m wrote:
>> 1. system accounts including root can't directly access file or data
>> on this system;

Edwin van den Oetelaar <newsgroups(a)oetelaar.com> wrote:
>That would be strange.

Agreed. Securing against root is somewhere between very difficult and
impossible, depending on exact OS you're using. Even with hardware encryption
support, a clever root user can find ways to get the keys.

Move such sensitive data to a system you can secure for real by not making
root available to people with lower priveleges.

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

Root can still get the keys or data out of memory, and/or patch the
application to alter the data at runtime. Among other things.

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

Nope. Root has control over the application.

>> Is there conceptual wrong in this requirement?

>I think so.
>Where / Why is this strange setup required? Is the rest of the system as
>secure? SSH/Certificates etc?

Agreed. This set of requirements is broken. Don't secure a system against
root, instead move the system to a secure one with different root access.
Having your webserver(s) be on different physical host(s) than your data
storage and security system(s) is fairly reasonable. Having them on the same
box and secure from root abuse is nigh impossible.

If you do what you're asking, you're guaranteed to get it wrong, and be no
more secure than if you just ignored the requirement to start with. Actually,
you'll be less secure because there's a class of threats you think you're
protected against when you're not.
--
Mark Rafn dagon(a)dagon.net <http://www.dagon.net/>
From: lovecreatesbeauty on 10 Nov 2009 20:44
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_don.27t_other_users_have_access_to_the_mounted_filesystem.3F
From: Wanna-Be Sys Admin on 10 Nov 2009 23:17
lovecreatesbeauty(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;
> 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)
> 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;
>
>
> And I have some queries about it:
>
> 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?
>
> Thank you for your time.

Easily enough done, except the one aspect where you want a non
privileged user access to things and to deny root. Why not just set it
up to work how you want and accept that root can still do what root
should be able to do? If you can't trust root user, host the
application on your own server and lock root down (you'll likely find
more issues with trying to keep the system secure and sane with
thinking the Apache user can be controlled, to not have to worry so
much about root).
--
Not really a wanna-be, but I don't know everything.
 |  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?