LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Linux From Scratch
User Name
Password
Linux From Scratch This Forum is for the discussion of LFS.
LFS is a project that provides you with the steps necessary to build your own custom Linux system.

Notices


Reply
  Search this Thread
Old 03-17-2007, 04:41 PM   #1
na5m
Member
 
Registered: Jan 2005
Location: california
Distribution: O.A.M. (Overmonitoring Address Matrix) Release 2.2 with 2120 Patch
Posts: 37

Rep: Reputation: 17
PackageUser based package management


Today I have successfully built a Linux From Scratch system from the lfslivecd-x68-6.2-5 LiveCD. I built it using the (rather dated) package-user hint: http://www.linuxfromscratch.org/hint...nd_pkg_man.txt. I configured, built, and installed just about everything as various package users (even the kernel!). It boots and seems to run fine. Actually, I was amazed that I could build and install the kernel as an unprivileged user and still have the system boot (yes, the kernel itself is owned by an non-root user! I had to make /boot a sticky directory, however. In fact, I had to make many directories sticky). My questions to any guru's out there are:
1)What are some of the ramifications of not having root own most of the system files and directories? For example, in most distributions, a non-root user cannot create or delete a file from, say, /sbin. But since I have made /sbin a sticky directory, anyone can write to it, delete their own stuff, etc. (but cannot delete others' stuff). This doesn't seem to really pose any kind of security risk. Any thoughts?

2)What are some of the ramifications of having the kernel belonging to a non-root user? Linux doesn't seem to care, as I can boot the kernel with no complaints. More thoughts?

3)So, why should root own anything at all in a linux distribution? (well, I guess root does have to own at least some minimum of things. Root's home dir, /root, for example, and a few setuid programs).
Having packages be owned by package users seems so logical to me, and I would like to have it implemented on my system as pervasively as is practical. I would really love to hear about anyone else's ideas, experiences, opinions, etc. on this subject.

Thanks a million!
na5m
 
Old 03-18-2007, 09:53 AM   #2
{BBI}Nexus{BBI}
Senior Member
 
Registered: Jan 2005
Location: Nottingham, UK
Distribution: Mageia 6, KDE Neon
Posts: 4,313

Rep: Reputation: 212Reputation: 212Reputation: 212
I suppose there's no problem if you're confident you won't be hacked, from a security stand point to have critical parts of Linux owned by non-privilaged user/s is a bad choice. That's like leaving your car keys in the door and trusting people not to get in and drive it away!

Last edited by {BBI}Nexus{BBI}; 03-18-2007 at 09:55 AM.
 
Old 03-18-2007, 12:00 PM   #3
na5m
Member
 
Registered: Jan 2005
Location: california
Distribution: O.A.M. (Overmonitoring Address Matrix) Release 2.2 with 2120 Patch
Posts: 37

Original Poster
Rep: Reputation: 17
How can you hack me?


(Nexus, as a non-root user who is currently logged onto my system),
please describe for me how I can be hacked (owing to the package-user
method that my system is using)? Can these 'critical' files be deleted
or modified by anyone other than their owner? I don't see how. Can
these 'critical' files be used to modify any system configuration
files? Again, I don't see how. Can these 'critical' files be used to
increase a normal user's rights, powers, authority, privileges, or
influence on the system? I don't think so. Can you become root on my
system? I doubt it.

If you were able to circumvent any of the above, then I would bet that
the same exploit could be used with equal success on a regular Linux
installation (one that assigns root to be the owner of most of the system
files).

I really feel that it all boils down to proper file permissions and file/group
ownership and membership. But please, I would like to know if you do have
a specific example of how I can be hacked, due to my files being owned by
non-root accounts.

na5m

 
Old 03-18-2007, 06:34 PM   #4
{BBI}Nexus{BBI}
Senior Member
 
Registered: Jan 2005
Location: Nottingham, UK
Distribution: Mageia 6, KDE Neon
Posts: 4,313

Rep: Reputation: 212Reputation: 212Reputation: 212
Wow, you invite a response and subsquently spit your dummy out when you get one!

Now I never claimed to have the expertise to 'hack' your system, but I'm sure even you would agree that there are such capable people/persons out there.

The WWW is littered with examples and stories of systems with security measures in place being hacked so what chance do you think you have? and if such a thing were to happen to you (heaven forbid) would you be man enough to admit it? Who knows.

The technique you are employing flys in the face of most if not all expert advice in running a secure system.

I truly hope you don't connect your system to the WWW as it stands, you would be like nectar to the bee.

Don't take offence at what I am saying this is not a flaming match, it's just my opinion.

Last edited by {BBI}Nexus{BBI}; 03-18-2007 at 08:52 PM.
 
Old 03-18-2007, 10:42 PM   #5
na5m
Member
 
Registered: Jan 2005
Location: california
Distribution: O.A.M. (Overmonitoring Address Matrix) Release 2.2 with 2120 Patch
Posts: 37

Original Poster
Rep: Reputation: 17
I'm sorry, Nexus. I truly didn't mean to come accross like that .
(My post does indeed sound unnecessarily terse.) But to the point: all that
I am trying to do is find out if my system truly is grossly non-secure.
People are used to seeing 99% of Linux system files and dirs owned by root.
But is a system (with proper permissions, etc) truly less secure if
these crucial files are not owned by root?

I would call myself fairly knowledgeable when it comes to Linux, but
not when it comes to Linux security. I've been trying to hack my own box,
in my own limited way, but so far I haven't been able to wreck the file
system, su to other users, etc.

PS- 'spit your dummy out'? I like that one
 
Old 03-20-2007, 02:57 AM   #6
Zention
Member
 
Registered: Mar 2007
Posts: 119

Rep: Reputation: 16
I have been looking into the user/package name install approach as well. Most people have to think a little bit before they understand the approach, it is NOT like leaving your keys in the car security problem.

In fact on par it should offer more security, root suid executables are problematic they are vulnerable to buffer overflow attacks and therefore offer a chance at privilege escalation - whilst of course you can secure against this anyhow, by having to think about what should be set as the user of a particular executable you can reduce the number of suid root executables in your system.

The viable problems with the approach center around the sheer number of extra users you will be adding to the system. The user system of unix was not designed for this - but do note some applications work well with an extra user added, they tend to be the daemon ones.

NFS limits the number of users (debatable) and groups it works with - this is just one example, there maybe be other gotchas in the wings, still most should be manageable.

As to setting directories sticky, I would be inclined to setup some groups to help manage what groups of packages should have access to - I think with the NFS problem making a group for every package may be overkill.

The other problem with allowing full access to your system directories is someone just maxing out that partition the directory resides on, so best not to allow access.

SELinux uses file attributes obviously with more features - perhaps something could be done there as well for a package manager.

I cannot see the security hole in using this approach and do wonder if people get confused by LFS documentation requesting people to chown to root some files in the install; that is a different matter of perhaps a user being given the uid of the old user from the other system.

I personally cannot see why root should own most of the files on a system - so yeah I will be moving over to user names for packages very shortly myself on my systems (not production), it does seem very compelling.
 
Old 03-20-2007, 02:28 PM   #7
na5m
Member
 
Registered: Jan 2005
Location: california
Distribution: O.A.M. (Overmonitoring Address Matrix) Release 2.2 with 2120 Patch
Posts: 37

Original Poster
Rep: Reputation: 17
Thanks for the opinion, Zention. That is exactly what I wanted my post to elicit:
peoples' views and/or experiences with this sort of package/user arrangment.

The owner of a file is, in part, irrelevant. What is relevant is who the
invoker is. The kernel allows certain commands to run only when they are
invoked by root, without regard to who the owner is.

I agree that the package-user system is not quite the same thing as leaving
keys in a car. Anyone the car didn't belong to could take the car, without
any special thieving skills, whereas not just anyone could take control of
the root account in a package-user system (without some skills at hacking).

Having sticky system directories does pose a problem with them becoming filled
up, like you said. Maybe for that reason alone, the package-user system is
undesirable. And having normal users be able to save their files to these
system directories isn't an appealing idea.

Are there any other security issues specific to package-user that you can
think of? Thanks everyone!

na5m
 
Old 03-21-2007, 03:07 PM   #8
Zention
Member
 
Registered: Mar 2007
Posts: 119

Rep: Reputation: 16
Could you post what you think the permissions should be on say /sbin and /usr/bin.

I think the way to do user based package management is:

Define a group eg. package

Now on the make install I think you have a couple of options:

Switch to the user to install the files in which case the user belongs to package group.

perms on the sbin directory could be rwxrwx--- the owner being root and the group being package.

perms on the /usr/bin directory could be rwxrwxr-x yet again owner is root and the group package.

Now that would allow the 'package user' to install into those directories, but no user outside the group of package or root could.

root is all powerful; being the root account means permissions are meaningless in nearly all instances (attributes can block, but of course root can reassign those). Being root means the code does not have to check permissions I would wager.

So, one could go a step further and create another account, let's call it admin.

admin is a user account without the all encompassing powers of root.

sbin could be setup like rwx------ with the owner being admin.

Prior to installation the files to be installed are created so as to have the ownership set to the package name. The admin user installs the files to sbin.

So, really the only places you need the sticky bit (T) set for directories is where data is variable under normal operation (ie not upon installation) the /tmp directory springs to mind here.

For partitions like /usr & even perhaps / you can specify them to be mounted as read only.

You could also add a little section to them that only root can access to be even more sure of some working space.

When you install packages the partitions would have to be remounted with the flags switched to read write. mount does allow for this with the remount option - but I would have to prove this to myself on a running system (I have borked a BSD system by trying to send a umount && mount fast) so I will test it now:

well it does work

> touch test1
> mount -o remount -o ro /
> touch test2
> mount -o remount -o rw /
> touch test3

use at own risk and of course the pwd is assumed to be on /

So, yeah I think the use of sticky bits littered around the system is odd, they should only be used in very specific places.

The user package system really only tends to improve the association of file to package, by hardwiring that relationship to the file - which is actually quite useful for many things when maintaining a system of course you are not limited to only that approach you can mix it with other ideas - you could still have a datastore of packages and their files.

The next step with the idea is to actually have the programs running as those users. This will make sure that any files, generated by the program during its operation, are owned by the program. I think this is a step too far and I suspect suid'ing would happen a lot unless some filter was used. It would offer fine control of each application, but I do think this is perhaps more in the realm of services rather than all applications, and applications should be built for this purpose (but worth mulling over).

SELinux takes this approach by adding in attributes to each file but it is supported specifically by kernel operations.

You may be wondering why many distros don't use the above approaches, even the source based ones, it is because of generality and the total number of packages they maintain.

The generality manifests in having to provide a solution to most people. Adding in layers that make it harder to install packages whilst also taking into account different partition setups is one layer of complexity too far.

Distros offer thousands of packages so they would have to have a user per package on the main build system that would make the user management systems there a bit daunting (though of course a particular user may only have a few hundred of those packages installed).

Building your own Linux/BSD box though means you are free to customise completely the solution.

So, say you were building a package system to create a number of firewall, router, web or database hosts or even development hosts that extra layer of customization comes in quite handy.
 
Old 03-21-2007, 08:45 PM   #9
na5m
Member
 
Registered: Jan 2005
Location: california
Distribution: O.A.M. (Overmonitoring Address Matrix) Release 2.2 with 2120 Patch
Posts: 37

Original Poster
Rep: Reputation: 17
If you set the perms on the dir /bin or /usr/bin to
Code:
drwxrwx---
then you will wind up with only two entities that can write (install files) into the directory: root, and the particular package you are installing. Since the files in /bin and /usr/bin come from multiple packages, you'll inevitably wind up with "permission denied" errors when installing. Since there are so many other packages that install to those dirs, I think you really need to do something with the "others" portion of the permissions trio (like make it writeable and/or sticky). That's why I've had to make many of my dirs sticky.

And I think you're right, Zention. With modern distros having hundreds and even thousands of packages (and each of those having differing version numbers), the package-user approach becomes unwieldy without the use of sophisticated package management utilities (and I am not aware of any such utilities for the package-user scheme, except for the simple ones provided in the LFS hints.
 
Old 03-21-2007, 08:48 PM   #10
Zention
Member
 
Registered: Mar 2007
Posts: 119

Rep: Reputation: 16
If group is rwx then anything belonging to the group can write to the directory.

So, you make the group of the user packages into package, or pkggrp if that makes it clearer.

So, all your package users belong to the group of pkggrp, that way the group entity can literally be thousands of users.

A group contains a number of users and a user can be in many groups.

Multiple versions on systems is something else, most systems will stick to one version but of course some are now offering the concept of slots.

Last edited by Zention; 03-21-2007 at 08:53 PM.
 
Old 03-21-2007, 10:25 PM   #11
na5m
Member
 
Registered: Jan 2005
Location: california
Distribution: O.A.M. (Overmonitoring Address Matrix) Release 2.2 with 2120 Patch
Posts: 37

Original Poster
Rep: Reputation: 17
Ah, now I see what you're saying. But now it just occurred to me about what you said in post #8: if the owner of a file is root and the group of a file is pkggrp, then that defeats the purpose of relating a file to its package, doesn't it? The name of my package, foo, has to show up on 'ls -l' as either the group or the owner (or both) so that I can tell what package installed a particular file.
 
Old 03-22-2007, 02:07 AM   #12
Zention
Member
 
Registered: Mar 2007
Posts: 119

Rep: Reputation: 16
I mention that /sbin is owned by root not the files contained within /sbin.

So, your sbin could look like this:

drwxrwx--- 2 root pkggrp /sbin

and a file could be:

-rwx------ 1 net-tools pkggrp route

This allows only the members of pkggrp group to install into /sbin (and of course root)

There are problems when you want to not use root to install, you have to secure pkggrp access and each package user's access.

I can see why adding the sticky bit would be of use here to stop the clobering of files so yes it is applicable in this scenario (though note the sticky bit being used does not allow all to add to the /sbin directory only those users in pkggrp).

Using root to install you can have:

drwx------ 2 root root /sbin
-rwx------ 1 net-tools anygrp route

or even to fully eradicate the existance of root as owner.

drwx------ 2 admin anygrp /sbin
-rwx------ 1 net-tools anygrp route

you can also then never have net-tools as a login user and secure it with randomly hard to crack password just in case. No stickybit is required as only root or admin would have or need write access to the directory.

I have assumed that /sbin will contain only files that the root user or admin is allowed and to be fair that is not a bad assessment.

the /bin directory could look like:

drwxrwxr-x 2 root pkgrp /bin
-rwxr-xr-x 1 core-utils pkgrp cat

drwxr-xr-x 2 root root /bin
-rwxr-xr-x 1 core-utils anygrp cat

drwxr-xr-x 2 admin anygrp /bin
-rwxr-xr-x 1 core-utils anygrp cat

Really the decision between installing as root or the user comes down to a few things:

1. As root, post install results in tighter perms on the system.
2. As package user, install access is limited to to the group(s) the user is in.

I think the real workaround is to use the concept of gates.

Install as the user but open the rwx access for the group at that point, then take it away post install.

Same as remounting the drive rw ro gate, I think that is quite a secure way to do things.

It only gives a passing window of opportunity rather than a static one.

You can turn on and off the sticky bit as well for added assurance.

Yeah I am starting to warm to that approach - part of the idea (well the initial hook of the hint) is you are stopping packages installing willy nilly all over the system so installing as root is giving back that power.

My eventual approach to package management will be a mix of a few techniques (I want a belt, braces, elasticated waistband, velcro fastening, a couple of covered internal buttons, one of those metal hooks beloved by combat trousers oh and a second set of underwear - anyway you get the idea ) but I don't want to allow one method to compensate for another.

Last edited by Zention; 03-22-2007 at 02:16 AM.
 
Old 03-24-2007, 10:53 PM   #13
na5m
Member
 
Registered: Jan 2005
Location: california
Distribution: O.A.M. (Overmonitoring Address Matrix) Release 2.2 with 2120 Patch
Posts: 37

Original Poster
Rep: Reputation: 17
The more I think about it and utilize it, the more I believe that using the sticky bit so widely, as is required by the more_control_and_pkg_man hint, is not a very good idea at all. Especially on a system with multiple users. I am becoming unhappy this style of package management
 
Old 03-26-2007, 05:08 PM   #14
Zention
Member
 
Registered: Mar 2007
Posts: 119

Rep: Reputation: 16
Well what do you mean by the stickybit?

The stickybit is used in directories (not plain old files) means that only the owner of the file or the owner of the directory may remove the file in that directory.

The stickybit is giving added protection.

It is the permissions that you should be concerned with.

It is the write flag being set that is the problem not the sticky.

The hints are just that, hints - this is why I am interested in a discussion about user based package management.

So, having a directory set

drwxrwx--T user1 users adir
-rw-rw---- user1 users afile

will allow any member of users to add, read or modify their own files.

It will not allow any user to delete a file even if the file is writable, though it will allow you to remove all the contents of that file:

and this is also true with a dir perms of:

drwxr-x--T user1 user adir

-rw-rw---- user1 users afile : user2 can still modify the afile, cannot delete though

Here we stop any user (bar user1) from adding files to the directory.

The T (stickybit) is superfluous here though.

The directory may as well be:

drwxr-x---

So in short, you add the sticky bit when you allow access in the install along with write on the group of the directory (but all files within should not allow group write).

Post install you remove the write access on the group of the directory (and the stickybit if you like it no longer serves a purpose).

So you end up with two sets of perms:

When installing:

drwxrwxr-t admin package bin
-rwxr-xr-x net-tools package route

Post install:

drwr-xr-x admin package bin
-rwxr-xr-x net-tools package route

The stickybit only helps in not deleting files where the group or other is set to write.

The files contained within should ONLY be writable on the owner(user) perm. It is that element that stops the nobbling of the files by rogue packages.

The sticky bit is stopping you deleting them when you have write access to the directory but not modifying them (which means you are not preventing nobbling).

eg. anyone in the package group can delete afile if the perms are:

drwxrwx--- admin package bin
-r-x----- net-tools package afile

That is by virtue of no stickybit and the write on the group of bin/.

Take the write away and it cannot be deleted but then you cannot add files to the directory, so you use the sticky bit to allow add (along with the write flag on group of the directory) and because there is no write on the files' groups perms you cannot modify.

I am actually doing tests as I write this and I would encourage you to do so as well - it is easy to not fully understand how the perms are actually working.

Last edited by Zention; 03-26-2007 at 05:17 PM.
 
Old 03-26-2007, 07:11 PM   #15
Zention
Member
 
Registered: Mar 2007
Posts: 119

Rep: Reputation: 16
Having write and execute only access on a directory means:

1. You can write new files in that directory.
2. You can delete files in that directory.
3. You can modify files only if the file itself allows write access.
4. You cannot read the list of files in a directory.

Having only execute access on a directory means:

1. You cannot write new files to that directory.
2. You cannot delete files in that directory.
3. You can modify files only if that file itself allows write access.
4. You cannot read the list of files in a directory but you can read the contents of files you have read access to.
5. You can cd to that directory.


Having only read access only on a directory means:

1. You cannot write new files to that directory.
2. You cannot delete files in that directory.
3. You cannot modify files in that directory.
4. You can read a list of files in that directory but not their contents even if you have read access to the file.
5. You cannot cd to that directory.

Having only write access to a directory means:

You cannot do anything.

So, that in itself is a bit odd.

The execute enables write for directories.

I think the reason this anomaly has occurred is because the directory perms concept has been created on top of the perms concept for files.

So, the perms are different for directories when compared with file perms.

Point 4 on the read access list is of interest as well - it does highlight that directory perms do not flow onto file perms contained within.

Having read and execute perms on a directory means:

1. You cannot write new files to that directory.
2. You cannot delete files in that directory
3. You can modify files only if the file itself allows write access
4. You can read a list of files and their contents only if the file itself allows read access.

So, execute is the perm that allows for reading a files contents and writing to a file if the file perms themselves allow for it.

Read access just you can get a list of files in the directory.

The big boy is execute access that is thing that relates to the files perms within if you like. If x is there then depending if the file has perms you can modify the files permissions if you like.


Now for all intents and purposes you are going to have to allow x if anyone wishes to work with the files, but I suppose you could nobble read as well on directories.

If execute and read perms allowed on a file within a directory (where only x is set) you can run that file even if read perm is off on the directory.

mkdir -m 710 test
cd test
echo -e "#\!/bin/bash\necho hello\ncdtest\nls -l" > test.sh
chmod 750 test.sh

switch user

test/test.sh

will echo hello and you will get a permission denied on the ls -l.

Flipping the write access on to the directory

rwx-wx--- user1 users test

even allows

switch user

cd test
mkdir user2directory
cd user2directory
touch demo1
ls -l

So, directory perms do not flow down the directory line either. Though of course if you remove execute perms on the group of the test directory you will prevent access to the user2directory.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
User Based Package Management System Chowroc Linux From Scratch 2 03-16-2007 05:30 PM
LXer: Simple Package management with Synaptic Package Manager LXer Syndicated Linux News 0 12-05-2006 07:33 PM
Using Package Archive style package management mugwump84 Linux From Scratch 3 08-25-2005 06:19 PM
Looking for a web based password management system jfall Linux - Software 1 05-07-2005 08:41 AM
Browser based DNS management depdiver Linux - Networking 2 01-28-2005 10:30 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Linux From Scratch

All times are GMT -5. The time now is 05:03 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration