LinuxQuestions.org
Visit the LQ Articles and Editorials section
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices



Reply
 
Search this Thread
Old 05-05-2010, 07:46 AM   #1
grail
Guru
 
Registered: Sep 2009
Location: Perth
Distribution: Manjaro
Posts: 7,698

Rep: Reputation: 1988Reputation: 1988Reputation: 1988Reputation: 1988Reputation: 1988Reputation: 1988Reputation: 1988Reputation: 1988Reputation: 1988Reputation: 1988Reputation: 1988
Pitfalls to using passwordless accounts


Just really looking for feedback/opinions.

I am setting up a package manager that installs or software as a user
named after the application, ie gcc is installed by user gcc.

The scripts I have written need to be launched as root who after checking dependencies and stuff su's into the gcc and installs the
software.

My question is this, is there any inherent security issues to this format?
Is it at all possible for a malicious user to somehow gain control over one of these users?
Are there other risks I should be aware of?

Any feedback is appreciated
 
Old 05-05-2010, 10:11 AM   #2
crts
Senior Member
 
Registered: Jan 2010
Posts: 1,604

Rep: Reputation: 446Reputation: 446Reputation: 446Reputation: 446Reputation: 446
Hi,

Since under Distribution you state that you are creating one I guess that by
Quote:
I am setting up a package manager that installs or software as a user ...
you mean
Quote:
I am setting up a package manager that installs our software as a user ...
As for your questions, here is some interesting info:
http://www.linuxfromscratch.org/hint...nd_pkg_man.txt

Are you using the same approach or a modified one? I used this approach for my LFS and I can tell you that you will run into a lot of permission issues, especially when installing man pages. As for security issues, well, according to the link I posted before this approach is also intended to increase security.

Another issue is that the user:group model's purpose is to manage access permissions in linux. Since with a user based package manager the user's primary function is to hold information of the package it belongs to, you only have the group left for access control. So you might also want to implement FACL into your distro. I wasn't very fond of FACL and deemed the advantages of it as marginal, at best. That is, until I implemented a user based package management into my LFS.

Not sure if this helps you but your question was very general.
 
Old 05-05-2010, 10:58 PM   #3
grail
Guru
 
Registered: Sep 2009
Location: Perth
Distribution: Manjaro
Posts: 7,698

Original Poster
Rep: Reputation: 1988Reputation: 1988Reputation: 1988Reputation: 1988Reputation: 1988Reputation: 1988Reputation: 1988Reputation: 1988Reputation: 1988Reputation: 1988Reputation: 1988
Hi crts
Cheers for your input

Firstly, thanks for picking up the typo, the or should have not been there at all. I was typing something and didn't delete back far enough
Quote:
I am setting up a package manager that installs software as a user ...
Yes mine is a modified approach based on the link as started a CLFS 64bit build.

I have not run into issues with man (yet).
I have looked at acl but yet to implement. Currently I name the user:group both after package, ie gcc - gcc:gcc

So currently I have the following:
1. All top level directories created prior to install of applications (using LFS/CLFS format) are owner:group - root:install with perms 775
2. All applications installed with owner:group - application:application with perms as outlined by installation
3. If application updates/writes to file/directory owned by another app then it has original owner's group name as additional group
4. If step 3 occurs then installation of owner application will alter permissions at the group level as applicable
5. All application owners have "install" as part of their groups

Quote:
Not sure if this helps you but your question was very general.
Yes helps heaps. Was trying to be general so as to get a broad scope of comments (if any)

Thanks again
 
Old 05-06-2010, 09:00 AM   #4
crts
Senior Member
 
Registered: Jan 2010
Posts: 1,604

Rep: Reputation: 446Reputation: 446Reputation: 446Reputation: 446Reputation: 446
Hi grail,

it is good to see that there are other people out there who use the user based package manager. You can have a look at the LFS forum since there also have been some posts regarding this package technique recently. However, I am not sure if the problems there also apply to CLFS.
As for ACL, let me state at this point that I also do not have it implemented yet. I only had some theoretical thoughts on this issue. In a single user environment there might not be a need to implement ACL. But here is the problem I see in a multiuser environment:

Let us assume we have a package - let's call it pkg - which installs a program that has to be suid. Now the default owner:group would be pkg:pkg. Since it needs to be suid this would have to be changed to something like something:pkg - and the permissions set accordingly. In a multiuser environment you might want to restrict access to this program only to some specific users. You can't do this by changing the group now because the package information would then be lost. There might also arise issues if you want to upgrade the package. The package user would no longer be permitted to modify the program due to lack of permissions if the group would also have been changed.
Adding the users to the 'pkg' group is also not an option since this would grant them access to all files of 'pkg'. This would definitely be a security risk since they would gain more privileges than necessary and intended to. So the only option that I see here is using ACLs.

But as I said, this is entirely theoretical.

As for your approach:
1. The install directory is also 'sticky' I guess, otherwise step 3/4 would be redundant.

3./4. If one of the packages were 'breached' by a malicious user then other packages might be 'endangered', too, if the compromised package has according secondary groups. Again, this is also a theoretical scenario.
If you want to exchange a file for a file that is also supplied by another group, then why not remove it as root prior installation/upgrade and then have it reinstalled by the desired alternative package?
Another possibility might be to change its ownership to the new group prior installation. E.g., if you want to replace a file that has been previously installed by 'pkg1' with a file that is supplied by 'pkg2', then you would change owner:group from pkg1:pkg1 to pkg2:pkg2. This way it can be overwritten by 'pkg2'.
I have used both approaches during installation of my LFS but I have not tried them on a running system in an upgrade situation. If you decide to do so, then some feedback about the process/problems is appreciated.

Last edited by crts; 05-06-2010 at 09:05 AM. Reason: disabled smilies ...
 
1 members found this post helpful.
  


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
recursion pitfalls icecubeflower Programming 5 11-24-2009 07:33 PM
Merging Linux local accounts with LDAP accounts Nortekman Linux - Server 1 05-04-2009 12:20 AM
Fetchmail with multiple mail accounts and local accounts lmcilwain Linux - Software 3 04-01-2007 03:58 PM
qmail -- new accounts can't receive mail, but old accounts can b:z *BSD 1 07-13-2005 01:42 AM
Avoiding pitfalls... tracedroute Slackware - Installation 6 05-09-2004 05:54 PM


All times are GMT -5. The time now is 12:14 AM.

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
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration