From: Thomas Walker Lynch Date: Sun, 6 Mar 2022 00:11:27 +0000 (-0500) Subject: expanding abreviations X-Git-Url: https://git.reasoningtechnology.com/style/static/git-logo.png?a=commitdiff_plain;h=7083d0e305d529225a00e7f378a9269019ff00b6;p=subu expanding abreviations --- diff --git a/doc/dir-structure.txt b/doc/dir-structure.txt deleted file mode 100644 index b385074..0000000 --- a/doc/dir-structure.txt +++ /dev/null @@ -1,38 +0,0 @@ - -~ is the project directory - --------------------------------------------------------------------------------- -most subdirectories are source modules - - --------------------------------------------------------------------------------- -~/tools - -Some tools are normally installed on the system. Others are local. Local tools -are typically standard tools that have been customized for the project or are -unusual to the project. - - ~/tools/bin is for the executables of locally used tools. - ~/tools/lib is locally used libraries. - ~/tools/doc is for collected docs on tools - -typically a developer will want ~/tools/bin in his search path - --------------------------------------------------------------------------------- -~/staged - -These are make file build targets. They represent either intermediate or -finished executables and libraries. When a project has multiple src -directories and they use each other's work product for the builds, the -items in the staged area are those that are used by each src directory. - -Typically the install target copies material in the staging area to -system locations. - --------------------------------------------------------------------------------- -~/ - - - - - diff --git a/doc/file_extentions.txt b/doc/file_extentions.txt deleted file mode 100644 index a9a2b21..0000000 --- a/doc/file_extentions.txt +++ /dev/null @@ -1,23 +0,0 @@ - - -filename.tag.extension - -extension: - .c for C source - .cc for C++ source - .h for C header file - .hh for C++ header file - .o an object file - -tag: - .lib. The resulting .o file to be placed in release library and is part of the - programming interface. - .aux. The resulting.o file not directly part of the programming interface, but - it might be called by functions that are. - .cli. The source file has a main call and is to be relased as part of the command line interface - .loc. file has a main call to be made into a local uitlity function - -We carry the source file tag and extension to the .o file. We do not put tags -nor extensions on command line executables. - -local_common.h should be included in all source files diff --git a/doc/makefile-issue b/doc/makefile-issue deleted file mode 100644 index 8916de0..0000000 --- a/doc/makefile-issue +++ /dev/null @@ -1,21 +0,0 @@ -1. - -For the following makefile, the .PHONY tag is ignored unless there -is an explicit target with that name. The %:: target is not enough. -So for expample, if there is an exec directory, the exec target -caught through the %:: will never fire. The commented lines must -be added that give an explicit exec target. - - -.PHONY: all version deps lib exec -all: version deps lib exec - -lib: - $(MAKE) $@ - cp src/tranche.lib.h include/tranche.h - -#exec: -# $(MAKE) $@ - -%:: - $(MAKE) $@ diff --git a/doc/note.txt b/doc/note.txt deleted file mode 100644 index b9ed603..0000000 --- a/doc/note.txt +++ /dev/null @@ -1,40 +0,0 @@ - -subu-mk-0 - - 1. We have to make the subu for step 2 so that we will have subu_uid and subu_gid - to work with, but we delay this for as long as possible, as the program might - first bail due to other errors. - - 2. Then we add user access via setfacl to masteru's home directory and to - subu_land, so that we have permissions to make the home directory. - - 3. Then as subu we create the home directory. .. I wonder where the system - gets the umask for this? Perhaps we should create the dir, and then change - the ownership instead? - - 4. Still as subu, we add facls to our directory to give masteru access. - -finished, good part is that we never need to move back to root. - -setfacl -m u:subu:x masteru -setfacl -m u:subu:x masteru/subu_land -setfacl -m d:u:masteru:rwX,u:masteru:rwX subu - - -using luseradd to make the subu is a circular problem because we need to setfacls -to allow the creating of the home directory inside the masteru/subu_land, but -to set facls we need the uid from luseradd. So.. - 1. luseradd without creation of a home directory. We can provide the path, - but can't create it. - 2. get the uid, and set the facls - 3. create the home directory - -Step 3 is a bit of a problem, because subu's don't have write permission for -subu_land/ - -.. or maybe not, luseradd puts users in /home, but those users don't have -write permissions there either, so I'll try and see what happens. - -given all the funky security stuff recently, I really need to call luseradd -to get the user added. Wish there was a C programming interface. My gosh, -python has one, and you can't if setuid root python programs. diff --git a/doc/real_uid.txt b/doc/real_uid.txt deleted file mode 100644 index b25e817..0000000 --- a/doc/real_uid.txt +++ /dev/null @@ -1,19 +0,0 @@ - -Real uid is a poorly named term for the uid of the user who launched the -process. The uid that the process has been set to is the effective uid. There -is a third stored uid in a process's record. Hence the uid being used by the -OS will be set to one of these. - -Our subu-mk-0 program wants to create a subservient user to a master user. The -master user is known via the real uid. The effective user will be that of root, -as the script needs root privilege to run adduser. - -sudo resets the real uid, and there is no reliable approch then to create a subu-mk-0 -program run by sudo. A setuid root program is needed. Only compiled executables can -be setuid root on linux. - -There is an environment variable given to programs run by sudo, $SUDO_USER. Sudo sets -it, so if called from sudo then that works. It could be set by another user, even -if that user is root or not. - -I will make a setuid C program. Too bad, had written this in Python. diff --git a/doc/real_uid_bug.pdf b/doc/real_uid_bug.pdf deleted file mode 100644 index 2d4a83d..0000000 Binary files a/doc/real_uid_bug.pdf and /dev/null differ diff --git a/doc/src.txt b/doc/src.txt deleted file mode 100644 index 902157b..0000000 --- a/doc/src.txt +++ /dev/null @@ -1,9 +0,0 @@ - - src-da a simple doubling size expanding array in C - src-tranche splits source code into multiple files. A poor man's 'makeheaders'. -src-dispatch runs a function or shell command as a separate process - src-db sqlite schema and interface for subu - src-0 The layer 0 commands for subu. Some are setuid root programs. - src-py The application layer - - diff --git a/doc/subu-mk-0.txt b/doc/subu-mk-0.txt deleted file mode 100644 index c3146bf..0000000 --- a/doc/subu-mk-0.txt +++ /dev/null @@ -1,104 +0,0 @@ -I. If we allowed the subu_home directory to be put anywhere, this script could - be used by masteru gain access to any directory on the system. Hence, we have - to add some constraints: - - constraint 1) the subuhome directory must not already exist, not as a - directory or as any other type of object. - - constraint 2) masteru must already have privledges to reach access $(masteru_home)/subuland - - constraint 3) subuhome may only be placed under the directory $(masteru_home)/subuland. - - convention 4) only subuhome directories may be placed in $(masteru_home)/subuland. - - -> without constraint 1), exploit 1 - - Suppose that a wily masteru was able to move an inaccessible directory that - he or she wanted access to and place it under $(masteru_home)/subuland. - Typically such directories are not moveable by wiley users in the first - place, but suppose the wily masteru found such a directory. - - Alternatively suppose the wily masteru made a directory under - $(masteru_home)/subuland of his or her own, and placed an inaccessible file - or subdirectory inside of it. - - Alternatively suppose that the wily masteru made $(masteru_home)/subuland a - hard link or a symlink to a directory that contained a subdirectory that - masteru did not have access to. - - The the wiley masteru could then create a subu by the same name as the - directory he desired access to, and trick the foolish subu-mk-0 into giving - him or her access. - - -> without constraint 2) exploit 2 - - Then the masteru could place subu directories in places he can not access. - The foolish subu-mk-0 program would then add 'x' acls to as to reach this - place. The masteru could then change identity to the subu, (i.e. enter the - container), and then reach that place he or she could not reach before. - - -> without constraint 3) exploit 3 - - If masteru looses x privlege to a place, subu might keep it, and then - exploit 2 would work despite the existence of constraint 2. It would be - unusual that masteru not have x privledges to masteru_home. Furthmore, we - decree that masteru has x privige to subuland. Hence, exploit 3 can be - prevented by following this convention. - - -> without convention 4) exploit 4 - - -II. the ownership flaw - -subu will own the files and directories that it makes. The default acls are -such that masteru will also have access to subu's file. This defines the master -user / subservient user convention on the filesystem. - -However, because subu owns the files and directories, it can modify the -acls. Thus a wily subu can lock the masteru out. - -Perhaps the master has a 'fix perms' script. However, there is no enshrined -relationship in the system between the masteru and the subu, so the system won't -know for sure the subu belongs to the masteru, and thus can not allow masteru to -change the supposed subu's permissions to give back access to masteru. - -Perhaps we propose that instead masteru owns the files and directories of -subuhome, and subu is given access privilege through acls and default acls. -Indeed, then subu can't change the acls on these existing files. However, if -subu is allowed to own processes, then those processes might create files owned -by the subu, and the subu can lock the master out from access to these new -files. - -How about a variation. Perhaps the subu shares the uid of the masteru, but has -a different gid. The subuhome then has the sticky bit set on the group access, -so all files created remain the same gid. subu process are masteru processes, -however the gid of the process is that of the subu's. Masteru can then control -both the files and the processes, but in absence of this control, the subu has -control. - -Then we don't make a new user when we make a subu, we make a new group. We then -have to add utilities for 'logging into the subu' which goes to a different home -directory based on the group being logged into. - -III. other approaches - -Groups don't seem to offer much help, the owner is still the owner. - -A volume can be mounted without the subu being able to modify the facls. I -don't know if the default facls still apply, but if so, then this would be a -solution. - -bindfs can translate uids and gids. The same directory can appear in two -places, in one place owned by the subu and in another owned by the masteru. -This looks to be potentially a clean solution. It would also be recursive, -i.e. a subu could have subus. I'll try this one. - -One possibility is for the subusers to appear in /home/ as normal users. Then -masteru bindfs with translation into subuland. Everything in subuland appears -to be owned by masteru. This is a transparent way to give masteru control over -all the files. - -Then is the question of being able to control the processes being run by a subu. -We will need an /etc/ file that pairs masters and subus. - - diff --git a/doc/subu.txt b/doc/subu.txt deleted file mode 100644 index d422784..0000000 --- a/doc/subu.txt +++ /dev/null @@ -1,68 +0,0 @@ - -subu is short for subservient user. - -A subu is much like any other user. It has an entry in /etc/passwd, and a home -directory. As for other users this home directory is most likely under /home. -Direct login to the subu might be barred, though that is not necessarly the case. - -Each subu has two names. One is its 'subu_username'. The other is its -'subuname'. The subu_username is autogenerated. When using our tools, one -never needs to know the subu_username. However, the entry in /etc/passwd will be -the generated name, and the home directory will have the generated name. The -command 'subu-username subuname' will print the subu_username. - -Each subu belongs to a master user, known as masteru. A given masteru may have many -subus. The masteru is a different user than any of the subu's that are -subservient to it. - -Each masteru has a top level subdirectory called 'subuland'. In this sub -directory the masteru will find all of its subu home directories. The masteru -will then see all subu owned files in the subuland through the illusion that the -masteru owns them rather than the corresponding subu. Thus the master may move -files around using a regular file navigator. - -Actually the subus will not appear in subuland until masteru runs the command -'subu-mount'. This is normally done when masteru logs in. - -The masteru may create and delete subus at will. The masteru may set default -nice values, renice, or kill subu processes. The masteru may set limits for a -subu. In fact, the masteru is a bit like root relative to its subus. - -There is a control panel that masteru may use. It has a matrix of rectangles, -where in each rectangle, there is information about each subu's processes and -disk usage. - -The masteru may set the subu for each launched process. - ---- -subu-username - -prints the username -returns an error code - ---- -subu-number - -prints a new maximums subu number. -returns an error code - -These numbers are used in synthesizing usernames. Used for testing, should not -appear in any scripts. - ---- -subu-mount - -mounts all of the subus for the given masteru -returns an error code - ---- -subu-mk-0 - -primitve makes a new subu -returns an error code - ---- -subu-rm-0 - -primitive removes a subu -returns an error code diff --git a/doc/subu_as_group.txt b/doc/subu_as_group.txt deleted file mode 100644 index 46da5b9..0000000 --- a/doc/subu_as_group.txt +++ /dev/null @@ -1,22 +0,0 @@ - -note the 'ownerhips flaw' in subu-mk-0.txt. Could groups help with this? - -Suppose that instead of creating the subu as a separate user, it is created as a group. Masteru then has a -number of separate groups. To run a process as the subu, the uid is set to the masteru, and the gid is set -to the subu. .. but then the process would be able to modify anything owned by masteru - -suppose subu belongs to masteru's group .. then all subus are the same and can write each other's data. - -suppose masteru belongs to subu's group .. subu is still its own unique user, so it can change group permissions -on files it makes and lock masteru out. - -suppose there is a unique third party, the mediator. Both masteru and subu belong to its group. A -processes running as subu can only create files in directories that have mediator group permissions. subu still -owns the files and directories it creates, so .. - -suppose the group sticky bit is set. The subu must belong to the group to write anything in the directories. -Anything it writes are owned by the group. Suppose masteru is also in the this group. Though a mean subu -could not take away the group ownership, it could - - - diff --git a/doc/todo.txt b/doc/todo.txt deleted file mode 100644 index b28b04f..0000000 --- a/doc/todo.txt +++ /dev/null @@ -1,3 +0,0 @@ - - - diff --git a/doc/try.txt b/doc/try.txt deleted file mode 100644 index c157aee..0000000 --- a/doc/try.txt +++ /dev/null @@ -1,5 +0,0 @@ - -sudo_leak_script - demonstrates script injection through the pompt environement variable -SUDO_USER - shows that userland scripts can trick other scripts into believing they are running under sudo. -print_env.py - prints getuid, geteuid, some other info, and the value of each environment variable -libuser - try out libuser diff --git a/document/dir-structure.txt b/document/dir-structure.txt new file mode 100644 index 0000000..b385074 --- /dev/null +++ b/document/dir-structure.txt @@ -0,0 +1,38 @@ + +~ is the project directory + +-------------------------------------------------------------------------------- +most subdirectories are source modules + + +-------------------------------------------------------------------------------- +~/tools + +Some tools are normally installed on the system. Others are local. Local tools +are typically standard tools that have been customized for the project or are +unusual to the project. + + ~/tools/bin is for the executables of locally used tools. + ~/tools/lib is locally used libraries. + ~/tools/doc is for collected docs on tools + +typically a developer will want ~/tools/bin in his search path + +-------------------------------------------------------------------------------- +~/staged + +These are make file build targets. They represent either intermediate or +finished executables and libraries. When a project has multiple src +directories and they use each other's work product for the builds, the +items in the staged area are those that are used by each src directory. + +Typically the install target copies material in the staging area to +system locations. + +-------------------------------------------------------------------------------- +~/ + + + + + diff --git a/document/file_extentions.txt b/document/file_extentions.txt new file mode 100644 index 0000000..a9a2b21 --- /dev/null +++ b/document/file_extentions.txt @@ -0,0 +1,23 @@ + + +filename.tag.extension + +extension: + .c for C source + .cc for C++ source + .h for C header file + .hh for C++ header file + .o an object file + +tag: + .lib. The resulting .o file to be placed in release library and is part of the + programming interface. + .aux. The resulting.o file not directly part of the programming interface, but + it might be called by functions that are. + .cli. The source file has a main call and is to be relased as part of the command line interface + .loc. file has a main call to be made into a local uitlity function + +We carry the source file tag and extension to the .o file. We do not put tags +nor extensions on command line executables. + +local_common.h should be included in all source files diff --git a/document/makefile-issue b/document/makefile-issue new file mode 100644 index 0000000..8916de0 --- /dev/null +++ b/document/makefile-issue @@ -0,0 +1,21 @@ +1. + +For the following makefile, the .PHONY tag is ignored unless there +is an explicit target with that name. The %:: target is not enough. +So for expample, if there is an exec directory, the exec target +caught through the %:: will never fire. The commented lines must +be added that give an explicit exec target. + + +.PHONY: all version deps lib exec +all: version deps lib exec + +lib: + $(MAKE) $@ + cp src/tranche.lib.h include/tranche.h + +#exec: +# $(MAKE) $@ + +%:: + $(MAKE) $@ diff --git a/document/note.txt b/document/note.txt new file mode 100644 index 0000000..b9ed603 --- /dev/null +++ b/document/note.txt @@ -0,0 +1,40 @@ + +subu-mk-0 + + 1. We have to make the subu for step 2 so that we will have subu_uid and subu_gid + to work with, but we delay this for as long as possible, as the program might + first bail due to other errors. + + 2. Then we add user access via setfacl to masteru's home directory and to + subu_land, so that we have permissions to make the home directory. + + 3. Then as subu we create the home directory. .. I wonder where the system + gets the umask for this? Perhaps we should create the dir, and then change + the ownership instead? + + 4. Still as subu, we add facls to our directory to give masteru access. + +finished, good part is that we never need to move back to root. + +setfacl -m u:subu:x masteru +setfacl -m u:subu:x masteru/subu_land +setfacl -m d:u:masteru:rwX,u:masteru:rwX subu + + +using luseradd to make the subu is a circular problem because we need to setfacls +to allow the creating of the home directory inside the masteru/subu_land, but +to set facls we need the uid from luseradd. So.. + 1. luseradd without creation of a home directory. We can provide the path, + but can't create it. + 2. get the uid, and set the facls + 3. create the home directory + +Step 3 is a bit of a problem, because subu's don't have write permission for +subu_land/ + +.. or maybe not, luseradd puts users in /home, but those users don't have +write permissions there either, so I'll try and see what happens. + +given all the funky security stuff recently, I really need to call luseradd +to get the user added. Wish there was a C programming interface. My gosh, +python has one, and you can't if setuid root python programs. diff --git a/document/real_uid.txt b/document/real_uid.txt new file mode 100644 index 0000000..b25e817 --- /dev/null +++ b/document/real_uid.txt @@ -0,0 +1,19 @@ + +Real uid is a poorly named term for the uid of the user who launched the +process. The uid that the process has been set to is the effective uid. There +is a third stored uid in a process's record. Hence the uid being used by the +OS will be set to one of these. + +Our subu-mk-0 program wants to create a subservient user to a master user. The +master user is known via the real uid. The effective user will be that of root, +as the script needs root privilege to run adduser. + +sudo resets the real uid, and there is no reliable approch then to create a subu-mk-0 +program run by sudo. A setuid root program is needed. Only compiled executables can +be setuid root on linux. + +There is an environment variable given to programs run by sudo, $SUDO_USER. Sudo sets +it, so if called from sudo then that works. It could be set by another user, even +if that user is root or not. + +I will make a setuid C program. Too bad, had written this in Python. diff --git a/document/real_uid_bug.pdf b/document/real_uid_bug.pdf new file mode 100644 index 0000000..2d4a83d Binary files /dev/null and b/document/real_uid_bug.pdf differ diff --git a/document/src.txt b/document/src.txt new file mode 100644 index 0000000..902157b --- /dev/null +++ b/document/src.txt @@ -0,0 +1,9 @@ + + src-da a simple doubling size expanding array in C + src-tranche splits source code into multiple files. A poor man's 'makeheaders'. +src-dispatch runs a function or shell command as a separate process + src-db sqlite schema and interface for subu + src-0 The layer 0 commands for subu. Some are setuid root programs. + src-py The application layer + + diff --git a/document/subu-mk-0.txt b/document/subu-mk-0.txt new file mode 100644 index 0000000..c3146bf --- /dev/null +++ b/document/subu-mk-0.txt @@ -0,0 +1,104 @@ +I. If we allowed the subu_home directory to be put anywhere, this script could + be used by masteru gain access to any directory on the system. Hence, we have + to add some constraints: + + constraint 1) the subuhome directory must not already exist, not as a + directory or as any other type of object. + + constraint 2) masteru must already have privledges to reach access $(masteru_home)/subuland + + constraint 3) subuhome may only be placed under the directory $(masteru_home)/subuland. + + convention 4) only subuhome directories may be placed in $(masteru_home)/subuland. + + -> without constraint 1), exploit 1 + + Suppose that a wily masteru was able to move an inaccessible directory that + he or she wanted access to and place it under $(masteru_home)/subuland. + Typically such directories are not moveable by wiley users in the first + place, but suppose the wily masteru found such a directory. + + Alternatively suppose the wily masteru made a directory under + $(masteru_home)/subuland of his or her own, and placed an inaccessible file + or subdirectory inside of it. + + Alternatively suppose that the wily masteru made $(masteru_home)/subuland a + hard link or a symlink to a directory that contained a subdirectory that + masteru did not have access to. + + The the wiley masteru could then create a subu by the same name as the + directory he desired access to, and trick the foolish subu-mk-0 into giving + him or her access. + + -> without constraint 2) exploit 2 + + Then the masteru could place subu directories in places he can not access. + The foolish subu-mk-0 program would then add 'x' acls to as to reach this + place. The masteru could then change identity to the subu, (i.e. enter the + container), and then reach that place he or she could not reach before. + + -> without constraint 3) exploit 3 + + If masteru looses x privlege to a place, subu might keep it, and then + exploit 2 would work despite the existence of constraint 2. It would be + unusual that masteru not have x privledges to masteru_home. Furthmore, we + decree that masteru has x privige to subuland. Hence, exploit 3 can be + prevented by following this convention. + + -> without convention 4) exploit 4 + + +II. the ownership flaw + +subu will own the files and directories that it makes. The default acls are +such that masteru will also have access to subu's file. This defines the master +user / subservient user convention on the filesystem. + +However, because subu owns the files and directories, it can modify the +acls. Thus a wily subu can lock the masteru out. + +Perhaps the master has a 'fix perms' script. However, there is no enshrined +relationship in the system between the masteru and the subu, so the system won't +know for sure the subu belongs to the masteru, and thus can not allow masteru to +change the supposed subu's permissions to give back access to masteru. + +Perhaps we propose that instead masteru owns the files and directories of +subuhome, and subu is given access privilege through acls and default acls. +Indeed, then subu can't change the acls on these existing files. However, if +subu is allowed to own processes, then those processes might create files owned +by the subu, and the subu can lock the master out from access to these new +files. + +How about a variation. Perhaps the subu shares the uid of the masteru, but has +a different gid. The subuhome then has the sticky bit set on the group access, +so all files created remain the same gid. subu process are masteru processes, +however the gid of the process is that of the subu's. Masteru can then control +both the files and the processes, but in absence of this control, the subu has +control. + +Then we don't make a new user when we make a subu, we make a new group. We then +have to add utilities for 'logging into the subu' which goes to a different home +directory based on the group being logged into. + +III. other approaches + +Groups don't seem to offer much help, the owner is still the owner. + +A volume can be mounted without the subu being able to modify the facls. I +don't know if the default facls still apply, but if so, then this would be a +solution. + +bindfs can translate uids and gids. The same directory can appear in two +places, in one place owned by the subu and in another owned by the masteru. +This looks to be potentially a clean solution. It would also be recursive, +i.e. a subu could have subus. I'll try this one. + +One possibility is for the subusers to appear in /home/ as normal users. Then +masteru bindfs with translation into subuland. Everything in subuland appears +to be owned by masteru. This is a transparent way to give masteru control over +all the files. + +Then is the question of being able to control the processes being run by a subu. +We will need an /etc/ file that pairs masters and subus. + + diff --git a/document/subu.txt b/document/subu.txt new file mode 100644 index 0000000..d422784 --- /dev/null +++ b/document/subu.txt @@ -0,0 +1,68 @@ + +subu is short for subservient user. + +A subu is much like any other user. It has an entry in /etc/passwd, and a home +directory. As for other users this home directory is most likely under /home. +Direct login to the subu might be barred, though that is not necessarly the case. + +Each subu has two names. One is its 'subu_username'. The other is its +'subuname'. The subu_username is autogenerated. When using our tools, one +never needs to know the subu_username. However, the entry in /etc/passwd will be +the generated name, and the home directory will have the generated name. The +command 'subu-username subuname' will print the subu_username. + +Each subu belongs to a master user, known as masteru. A given masteru may have many +subus. The masteru is a different user than any of the subu's that are +subservient to it. + +Each masteru has a top level subdirectory called 'subuland'. In this sub +directory the masteru will find all of its subu home directories. The masteru +will then see all subu owned files in the subuland through the illusion that the +masteru owns them rather than the corresponding subu. Thus the master may move +files around using a regular file navigator. + +Actually the subus will not appear in subuland until masteru runs the command +'subu-mount'. This is normally done when masteru logs in. + +The masteru may create and delete subus at will. The masteru may set default +nice values, renice, or kill subu processes. The masteru may set limits for a +subu. In fact, the masteru is a bit like root relative to its subus. + +There is a control panel that masteru may use. It has a matrix of rectangles, +where in each rectangle, there is information about each subu's processes and +disk usage. + +The masteru may set the subu for each launched process. + +--- +subu-username + +prints the username +returns an error code + +--- +subu-number + +prints a new maximums subu number. +returns an error code + +These numbers are used in synthesizing usernames. Used for testing, should not +appear in any scripts. + +--- +subu-mount + +mounts all of the subus for the given masteru +returns an error code + +--- +subu-mk-0 + +primitve makes a new subu +returns an error code + +--- +subu-rm-0 + +primitive removes a subu +returns an error code diff --git a/document/subu_as_group.txt b/document/subu_as_group.txt new file mode 100644 index 0000000..46da5b9 --- /dev/null +++ b/document/subu_as_group.txt @@ -0,0 +1,22 @@ + +note the 'ownerhips flaw' in subu-mk-0.txt. Could groups help with this? + +Suppose that instead of creating the subu as a separate user, it is created as a group. Masteru then has a +number of separate groups. To run a process as the subu, the uid is set to the masteru, and the gid is set +to the subu. .. but then the process would be able to modify anything owned by masteru + +suppose subu belongs to masteru's group .. then all subus are the same and can write each other's data. + +suppose masteru belongs to subu's group .. subu is still its own unique user, so it can change group permissions +on files it makes and lock masteru out. + +suppose there is a unique third party, the mediator. Both masteru and subu belong to its group. A +processes running as subu can only create files in directories that have mediator group permissions. subu still +owns the files and directories it creates, so .. + +suppose the group sticky bit is set. The subu must belong to the group to write anything in the directories. +Anything it writes are owned by the group. Suppose masteru is also in the this group. Though a mean subu +could not take away the group ownership, it could + + + diff --git a/document/todo.txt b/document/todo.txt new file mode 100644 index 0000000..b28b04f --- /dev/null +++ b/document/todo.txt @@ -0,0 +1,3 @@ + + + diff --git a/document/try.txt b/document/try.txt new file mode 100644 index 0000000..c157aee --- /dev/null +++ b/document/try.txt @@ -0,0 +1,5 @@ + +sudo_leak_script - demonstrates script injection through the pompt environement variable +SUDO_USER - shows that userland scripts can trick other scripts into believing they are running under sudo. +print_env.py - prints getuid, geteuid, some other info, and the value of each environment variable +libuser - try out libuser diff --git a/exec/subu_add b/exec/subu_add deleted file mode 100755 index abd732e..0000000 --- a/exec/subu_add +++ /dev/null @@ -1,35 +0,0 @@ -#!/bin/bash -# must have commands rsync and user-stem -# user-stem is in the system repo -# -# wish we could set the uids and gids so that backups would restore properly on other systems but it is too much trouble -# to do in a shell script. Perhaps in the python code for the actual release. - -subu=$1 - - -if [ ! -x "/usr/local/bin/user-stem" ]; then - echo "no /usr/local/bin/user-stem program found (it is in the system repo)" - exit 1 -fi - -if [ -z "$subu" ]; then - echo "no subuser name supplied" - exit 1 -fi - -# stem includes all characters up to the first '-' -stem=$(/usr/local/bin/user-stem) - -user_subu="$stem-$subu" -user_admin="$stem-admin" - -home_subu="/home/$stem/$subu" -home_admin="/home/$stem/admin" - -sudo useradd --home-dir "$home_subu" "$user_subu" -sudo usermod -aG "$user_subu" "$user_admin" -sudo find "$home_admin/subu_default" -mindepth 1 -execdir cp -p {} "$home_subu" \; -sudo find "$home_subu" -execdir chown "$user_subu":"$user_subu" {} \; - - diff --git a/exec/subu_del b/exec/subu_del deleted file mode 100755 index 2a9e474..0000000 --- a/exec/subu_del +++ /dev/null @@ -1,63 +0,0 @@ -#!/bin/bash -# must have command user-stem -# user-stem is in the system repo -# -# currently this is setup to be run by any user who has sudo - it doesn't have to be run by the user-admin account; though chances are it will be. -# -# userdel -r deletes both the /var/spool/mail/user and the user's home directory. We don't want to delete the old data just in case there -# is something important there. However we can not leve the old /var/spool/mail/user file under /var/spool/mail in case another subu is -# created later with the same name. Hence we will move the /var/spool/mail/user file into the users home directory. We will give ownership -# of the old home directory to the admin. -# -# I have run into a problem that subu users do not inherit the MAIL variable, I wouldn't trust it anyway. I do not know if userdel -r -# references the MAIL variable. I will hard code a local variable to /var/sppol/mail. This must be changed for systems that put the mail spool -# file eleswhere. -# -#set -x - -subu=$1 - -if [ ! -x "/usr/local/bin/user-stem" ]; then - echo "no /usr/local/bin/user-stem program found (it is in the system repo)" - exit 1 -fi - -if [ -z "$subu" ]; then - echo "no subuser name supplied" - exit 1 -fi - -# stem includes all characters up to the first '-' -stem=$(/usr/local/bin/user-stem) -user_subu="$stem-$subu" -user_admin="$stem-admin" -home_subu="/home/$stem/$subu" -archive_suffix=_former_subu -archive_subu="$home_subu$archive_suffix" -mail_source_dir="/var/spool/mail" -mail_source_file="$mail_source_dir/$user_subu" -mail_target_file="$home_subu/mail_spool" - -if [ -e "$archive_subu" ]; then - echo "there is already a saved directory for a deleted subu with this name, move this out of the way first: $archive_subu" - exit 1 -fi -if [ ! -d "$mail_source_dir" ]; then - echo "could not find mail spooler directory: $mail_source_dir" - exit 1 -fi - -if [ -e "$mail_target_file" ]; then - echo "there is already file system object where we planned to move the deleted user's mail spool, which is here: $home_subu/mail_spool" - exit 1 -fi - -sudo killall --signal 5 --user "$user_subu" -sudo mv "$mail_source_file" "$mail_target_file" -sudo chmod -R go-rwx "$home_subu" -sudo chown -R "$user_admin":"$user_admin" "$home_subu" -mv "$home_subu" "$archive_subu" -sudo groupdel -f "$user_subu" -sudo userdel "$user_subu" - -#set +x diff --git a/executable/ch_subu b/executable/ch_subu new file mode 100644 index 0000000..c7298fa --- /dev/null +++ b/executable/ch_subu @@ -0,0 +1,21 @@ +#!/bin/bash +# +# This must be sourced + +subu=$1 +if [ -z "$subu" ]; then + echo "no subuser name supplied" + exit 1 +fi + +machine="$(hostname)" +xkey=$(xauth list | grep Turbine | awk '{print $3}') + +if [ -z "$key" ]; then + echo "xauth key not found" + exit 1 +fi + +sudo su "$subu" + +xauth \ No newline at end of file diff --git a/executable/subu_add b/executable/subu_add new file mode 100755 index 0000000..abd732e --- /dev/null +++ b/executable/subu_add @@ -0,0 +1,35 @@ +#!/bin/bash +# must have commands rsync and user-stem +# user-stem is in the system repo +# +# wish we could set the uids and gids so that backups would restore properly on other systems but it is too much trouble +# to do in a shell script. Perhaps in the python code for the actual release. + +subu=$1 + + +if [ ! -x "/usr/local/bin/user-stem" ]; then + echo "no /usr/local/bin/user-stem program found (it is in the system repo)" + exit 1 +fi + +if [ -z "$subu" ]; then + echo "no subuser name supplied" + exit 1 +fi + +# stem includes all characters up to the first '-' +stem=$(/usr/local/bin/user-stem) + +user_subu="$stem-$subu" +user_admin="$stem-admin" + +home_subu="/home/$stem/$subu" +home_admin="/home/$stem/admin" + +sudo useradd --home-dir "$home_subu" "$user_subu" +sudo usermod -aG "$user_subu" "$user_admin" +sudo find "$home_admin/subu_default" -mindepth 1 -execdir cp -p {} "$home_subu" \; +sudo find "$home_subu" -execdir chown "$user_subu":"$user_subu" {} \; + + diff --git a/executable/subu_del b/executable/subu_del new file mode 100755 index 0000000..98fc7c4 --- /dev/null +++ b/executable/subu_del @@ -0,0 +1,63 @@ +#!/bin/bash +# must have command user-stem +# user-stem is in the system repo +# +# currently this is setup to be run by any user who has sudo - it doesn't have to be run by the user-admin account; though chances are it will be. +# +# userdel -r deletes both the /var/spool/mail/user and the user's home directory. We don't want to delete the old data just in case there +# is something important there. However we can not leve the old /var/spool/mail/user file under /var/spool/mail in case another subu is +# created later with the same name. Hence we will move the /var/spool/mail/user file into the users home directory. We will give ownership +# of the old home directory to the admin. +# +# I have run into a problem that subu users do not inherit the MAIL variable, I wouldn't trust it anyway. I do not know if userdel -r +# references the MAIL variable. I will hard code a local variable to /var/sppol/mail. This must be changed for systems that put the mail spool +# file eleswhere. +# +#set -x + +subu=$1 + +if [ ! -x "/usr/local/bin/user-stem" ]; then + echo "no /usr/local/bin/user-stem program found (it is in the system repo)" + exit 1 +fi + +if [ -z "$subu" ]; then + echo "no subuser name supplied" + exit 1 +fi + +# stem includes all characters up to the first '-' +stem=$(/usr/local/bin/user-stem) +user_subu="$stem-$subu" +user_admin="$stem-admin" +home_subu="/home/$stem/$subu" +archive_suffix=_former_subu +archive_subu="$home_subu$archive_suffix" +mail_source_dir="/var/spool/mail" +mail_source_file="$mail_source_dir/$user_subu" +mail_target_file="$home_subu/mail_spool" + +if [ -e "$archive_subu" ]; then + echo "there is already a saved directory for a deleted subu with this name, move this out of the way first: $archive_subu" + exit 1 +fi +if [ ! -d "$mail_source_dir" ]; then + echo "could not find mail spooler directory: $mail_source_dir" + exit 1 +fi + +if [ -e "$mail_target_file" ]; then + echo "there is already file system object where we planned to move the deleted user's mail spool, which is here: $home_subu/mail_spool" + exit 1 +fi + +sudo killall --signal 5 --wait --user "$user_subu" +sudo mv "$mail_source_file" "$mail_target_file" +sudo chmod -R go-rwx "$home_subu" +sudo chown -R "$user_admin":"$user_admin" "$home_subu" +mv "$home_subu" "$archive_subu" +sudo groupdel -f "$user_subu" +sudo userdel "$user_subu" + +#set +x diff --git a/executable/test b/executable/test new file mode 100644 index 0000000..88eea60 --- /dev/null +++ b/executable/test @@ -0,0 +1,6 @@ + +subu=$1 + +whoami +sudo su $subu +whoami \ No newline at end of file